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1.     INTRODUCTION 

Possibly  the  laroest  single  collection  of  computer  based 
instructional  material  in  the  world  is  written  in  the  TUTOR 
proaramminq  Unouage  C11#19]  fully  supported  only  by  the  PLATO 
system  [13  developed  by  the  Computer-based  Education  Reasearch 
Laboratories  (CFRL)  of  the  University  of  Illinois.  The  PLATO  system 
and  associated  TUTOR  language  have  evolved  together  over  the  last  10 
years/  and  combine  a  number  of  interesting  and  powerful  features 
that  are  not  widely  available  in  other  systems.  Thouch  intended 
primarily  for  the  structuring  of  instructional  material  tor  computer 
presentation*  the  TUT1.  R  language  has  been  used  for  information 
system  develorment  [243*  simulation  of  physician-patient  interaction 
113,14],  and  a  host  of  other  applications.  Subsets  of  TUTOR  have 
previously  been  implemented  by  others,  most  notably  in  the 
1ULTTTUT0R-  HYPERTEXT  system  at  Northwestern  University  [17,1fcD. 

This  paper  deals  with  the  design  and  implementation  of  a  run 
ime  support  system  for  TUTOR  in  <;  small  machine  environment.  The 
ntire  system  is  described  elsewhere  [?,.?, 7,*, 2?, 253. 

.1.    APPLICATIONS  FOR  A  SMALL  TUT0l<  SYSTEM 


T  h  *  PL^TO  system  uses  a  larqe  dual  [.rocessor  machine  with  two 
Ulion  words  of  60  bit  fxtended  Core  Storage  and  o  complex 
jltiplexor  system  to  drive  to  up  to  ITOU  terminals.  Startup  costs 
)r  such  a  system  are  quite  hioh,  as  are  communication  costs  if  the 
';er   community   is  geoo raph i ca I  I y  dispersed.   In  aodition,  the  size 
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o*  the  user  community  on  such  a  system  can  raise  serious  managerial 
and  security  problems.  fecause  of  this*  there  may  be  many 
applications  for  an  alternative  in  the  form  of  an  inexpensive  system 
of  2f)  to  30  terminals  with  the  capability  to  tie  into  networks  with 
similar  systems. 

The  feasibility  of  such  a  system  has  previously  been 
i nves t i oat er  with  favorable  results  C6]/  although  TUTOR  has  since 
evolved/   invalidating   some  of  the  design  decisions  of  this  earlier 

wori  . 


1.2;     THT  POSSIBILITY  OF  OTHER  LANGUAGES 

Currently  the  PLATO  system  supports  only  the  TUTOR  language  for 
the  development  of  interactive  programs*  and  there  is  no  commitment 
to  support  other  lanmjaoes  for  any  but  background  or  batch 
processing.  alternatives  to  TUTOR  need  to  be  explored/  particularly 
in  the  «ire;.  of  control  structures.  At  least  one  such  language  has 
teen  developed  and  implemented  on  PLATO  by  translation  to  TUTOR 
L 1 0  U  _  It  is  hoped  that  the  interpretation  technique  described  in 
this  paper  will  considerably  simplify  such  experiments. 


1.3 


PROJECT  f.OALS 


T  h  ^  principal  goal  addressed  here  is  the  demonstration  that 
TUT'R  can  be  supported  for  a  sinale  user  on  a  small  to  medium  scale 
machine  in  a  manner  compatible  with  extension  to  multiple  users. 
This  involves  an  analysis  of  the  different  features  of  TUTOR  showing 
either  that  they  are  compatible  with  such  an  environment/  or  if  not/ 
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that  the  cost  of  incompatibility  is  reasonable.  An  interpreter  and 
compiler  have  been  implemented  based  on  the  ideas  presented  here* 
and  a  limited  number  of  TUTOR  programs  have  teen  transferred  from 
PLATO. 

Because   of   the  speed  at  which  TUTOR  on  PLATO  is  evolving*  an 

important   subgoal   is  to   design   the   implementation  with  maximum 

flexibility  so  that  changes  can  be  incorporated  with  a  minimal 
amount  of  new  work. 

The  notation  and  terminology  used  here  are  largely  adopted  from 
the  PLATO  project;  for  instance/  command  names  are  enclosed  in 
dashes  (-dot-)*  and  names  of  special  characters  are  capitalized 
(FONT).  However*  TUTOR  lessons  are  referreo  to  as  programs  and 
students  as  users  in  order  to  emphasize  that  TUTOR  is  a  general 
puroi  se  Language  and  is  in  no  way  limited  to  instructional 
applications. 


The  following  chapter  discusses  the  general  nature  of  a  TUTOR 
program  and  the  different  constraints  on  how  it  may  be  represented 
and  interpreted  on  a  small  machine.  The  remaining  chapters  deal 
Similarly  with  the  special  areas  where  TUTOR  is  most  different  from 
conventional  programmino  languages*  specifically  the  areas  of  input 
analysis  or  judging*  program  seomentin-.  or  units*  «no  i  nput  /out  put . 
This  should  not  be  considered  as  a  complete  description  of  an 
implementation  of  TUTOR*  as  many  conventional  facilities  of  the 
language  are  only  briefly  covered*  if  at  all. 


Page 


?.     BASIC  DTSICN  CONSTRAINTS 

The   constraints   aovernino   the   way  TUTOR  is  implemented  fall 

into   three  Large  classes:   Those  introduced  by  the  target  hardware/ 

those   introduced  by  thr  TUTOR  languaoe/  and  these  introduced  by  the 

imp  I  ement or   for  other  reasons.   In  this  last  class  is  the  desire  to 

eventually   support   other   programmino   languages*  as   well  as  the 

desire   to   support   user   terminals  other  than  the  present  PLATO  IV 
terminal  . 

One  of  the  greatest  barriers  to  implementing  TUTOR  in  any  new 
environment  is  that  TUTOR  is  defined  in  terms  of  the  hardware  on 
which  it  is  implemented  at  CERL/  with  little  or  no  attention  to  the 
possibility  of  machine  i ndependen ce .  For  this  reason*  part  of  the 
problem  of  implementing  TUTOR  on  .  small  machine  lies  in  deciding 
which  aspects  of  the  original  machine  require  emulation/  and  which 
are  nonessential  to  the  definition  of  TUTOR. 

2.1.     DOMAINS  OVER  WHICH  TUTOR  EXECUTION  IS  DEFINED 


It  is  convenient  to  discuss  the  design  constraints  imposed  by 
the  TUTOR  Ian  uage  in  terms  of  the  resources  that  must  be  brought 
together  for  a  program  to  be  run.  In  this  context/  the  current 
PLATO  implementation/  as  well  as  the  available  implementation 
alternatives/  can  be  meaningfully  discussed  and  related  to  the 
pre lems  of  a  small  to  medium  scale  machine  environment. 
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2.1 .1 .     PROGRAM  SPACE 

The  program  to  be  executed  may  be  shared  by  many  different 
users/  all  executing  different  parts  of  it  in  a  time-shared  manner. 
On  PLATO/  the  programs  are  stored  in  Extended  Core  Storage  (ECS)/ 
and  when  a  user  wishes  to  execute  a  portion  of  a  pro cram/  logical 
segments  of  that  prooram  are  brought  into  central  memory  for 
execution.  These  segments/  called  'units'  on  PLATO/  provide  a 
virtual  memory  mechanism  tnat  allows  full  use  of  two  million  words 
of  ECS  by  a  central  processor  with  a  relatively  small  memory  of  its 
own . 

An  alternative  way  of  segmenting  TUTOR  programs  that  involves 
link  e  d  i  t  i  n  q  of  unit  clusters  has  been  proposed  C6J.  This  scheme 
relies  on  the  assumption  that  all  units  celled  from  any  unit  are 
known  at  compile  time;  thus/  it  should  te  possible  to  build  clusters 
pf  units  such  that  inter-cluster  linkage  is  minimized.  This  scheme 
may  be  attractive  in  env  i  ronrrent  s  where  large  seqment  sizes  are 
acceptable/  hut  constructs  such  as  -imain-  Csection  A. 1.1]  may 
invalidate  the  obove  assumption. 


The  TUTOR  units  on  PLATO  are  compiled  into  two  components:  The 
instruction  part  of  a  unit  is  a  list  of  60  bit  entries  containing 
encodings  of  the  command  names  and  parameters  or  pointers  to  other 
information.  The  second  part  of  each  unit  holes  the  additional 
information  reouired  by  the  commands  in  the  first  part.  The 
consecutive  list  of  commands  in  the  first  part  of  the  unit 
simplifies  the  linear  search  for  certain  commands  used  by  the 
judging  mechanism  [appendix  AD. 
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Pecause  many  TUTOR  commands  invoke  complex  system  functions  at 
run  time/  or  amount  to  complex  service  subroutine  calls*  TUTOR 
programs  will  always  consist  largely  ol  the  computation  of 
parameters  to  system  subroutines.  Directly  compilinq  TUTOR  code  to 
machine  code  could  consume  unreasonable  amounts  of  time  and  space 
because  of  the  expense  of  conventional  calling  sequences-  On  the 
other  hand/  qiven  the  paged  virtual  memory  capabilities  that  are 
becoming  common  on  medium  scale  machines*  some  de  -emphasi  zat  i  on  of 
the  TUTOR  unit  would  be  desirable. 

If  T  U  T  <  R  is  to  be  supporter1  in  a  demand  paging  environment/  it 
would  be  useful  to  merge  the  two  components  of  each  unit  in  order  to 
improve  program  locality.  The  MULTITUTOR  i mp lement ot ion  [17/183  has 
achieved  this  meroer  by  including  in  the  6f  bit  code  for  each 
command  a  pointer  to  the  next  command/  allowing  the  continued 
interpretation  of  judging  semantics  in  terms  of  a  scan  of  the 
(linked)   command   list.   In   fact/   the   run  time  scan  can  be  fully 

eliminated  from  the  interpretation  process  [chapter  33. 

i 

I 
2.1.2.     STUDENT  OR  USER  VARIABLES 


Each  user  of  a  TUTOR  program  has  a  unique  array  ot  150  words 
that  may  bf  used  for  user  dependent  computation.  These  user 
variables  retain  their  values  when  a  user  chanues  programs/  and  they 
are  saved  when  a  user  is  not  on  the  system;  tnus/  they  may  be  used 
for  inter-prooram  parameters  and  user  related  historic  data  so  lona 
as  all  prowrams  involved  agree  on  the  use  of  each  location.  There 
is   no   automatic   storage   allocation   mechanism/   nor  is  there  any 
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dynamic   storage  management  system  for  user  data*  though  it  is  hoped 
that  some  form  of  both  will  be  introduced  in  the  future. 

One  of  the  basic  assumptions  inherent  in  the  design  of  TUTOR  is 
that  all  data  types  will  fit  in  one  machine  word.  As  a  consequence/ 
TUTOR  aoes  not  need  or  have  any  data  type  enforcement  or  checking; 
instead/  the  dcta  type  must  be  provined  with  each  iremory  reference. 
For  example/  'n1'  refers  to  the  first  available  location  as  an 
integer/  'v1'  refers  to  it  as  a  tloating  point  number/  and 
alphanumeric  data  must  be  stored  packed  in  integers.  This 
assumption  is  acceptable  in  the  CERL  implementation  where  the 
machine  word  size  is  6  0  bits/  but  on  the  majority  of  available 
machines  in  the  small  to  medium  size  range/  the  common  16  or  32  bit 
word  size  could  pose  a  problem. 

The  word  length  must  be  comparable  to  60  bits  in  order  to  allow 
simple  program  interchange  with  PLATO;  on  smaller  machines/ 
representing  a  TUTOR  word  as  6 4  bits  is  reasonable  as  has  been 
previously  proposed  C6D.  f'any  available  machines  in  the  target 
class  have  standard  hardware  available  to  do  64  bit  floating  point 
arithmetic/  but  the  integer  representation  poses  some  problems  as  3  2 
tit  inteoer  arithmetic  is  the  largest  commonly  available  on  such 
machines. 


Representing  integers  by  the  3?  most  significant  bits  has  been 
propose i  elsewhere  [  6  D  but  could  introduce  many  problems  in  program 
conversion  because  of  the  amount  ot  explicit  bit  manipulation  that 
TUTOR  encourages.  For  the  Same  reason/  the  sign  bit  must  be  the 
most   significant   lit/  so  integers  may  be  represented  either  by  the 
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least  siqnificant  32  bits  of  a  word  with  sign  extension/  or  by  the 
full  6  A  bits  using  software  simulation.  Both  of  these  alternatives 
would  add  greatly  to  th'  size  of  programs  compiled  into  machine  code 
and  significantly  increase  execution  times  in  any  implementation. 
Thus  again/  some  form  of  interpretation  seems  preferable. 

P.1.3.     COMMON  OR  COMMUNICATION  VARIABLES 

An  important  capability  of  multiple  user  on-line  computer 
systems  that  is  frequently  not  well  supported  is  inter-user  or 
inter-pronram  communication.  Many  timesharine  systems  allow  user 
tasks  to  communicate  only  by  shared  disk  files  or  other  slow  and 
inelegant  means.  The  UNIX  syste n  L16J  provides  a  special  type  of 
logical  file  called  a  'pipe'  which  may  be  read  from  by  one  task 
after  beinq  written  on  by  another. 

TUTOR  provides  common  variables  as  a  solution  to  this  problem. 
If  i.  program  uses  common  variables/  all  users  of  that  program  will 
share  the  same  copy  of  them  (as  oppose d  to  user  variables  which  are 
unique  to  each  user).  In  addition/  common  variables  are  also 
preserved  when  no  users  are  attacheo/  so  they  may  be  used  by  the 
prooram  to  record  historic  information  and  constant  data.  Critical 
section  manc-qement  for  access  to  common  data  is  provided  by  the 
-reserve-  and  -release-  commands  which  operate  on  semaphores 
associated  with  each  named  common  block. 


On  PLATO/  common  variables  are  stored  in  ECS/  to  use  them  a 
m^ppinc  must  be  established  between  the  ECS  copy  and  a  1500  word 
central   memory  buffer  accessable  by  the  user  prooram.   This  mapping 
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is  implicit  if  the  size  of  the  common  is  less  than  1500  60  bit 
words/  but  must  be  explicitly  stated  for  larger  commons/  and  may  be 
changed  at  run  time.  Given  paged  virtual  memory  hardware  instead  of 
word  addressable  ECS/  these  arbitrary  mappings  n\py  be  quite 
difficult  to  support.  Fortunately*  only  about  one  fourth  of  all 
existing  TUTOR  programs  use  common  variables  at  all/  and  of  these 
only  a  fraction  use  more  than  the  1500  word  limit;  thus/  the 
translation  costs  imposed  by  incompatibility  in  the  support  of  large 
common  regions  should  not  be  objectionable. 

*  ■  < 

2.1.4.     ST0RAGT  OR  EXTENDED  USER  VARIABLES 

The  150  word  limit  on  the  number  of  user  variables  poses  a 
severe  restriction  on  the  utility  of  TOTiR  for  solving  many  classes 
of  problems.  Because  the  15  0  user  variables  retain  their  values 
between  sessions  for  any  oiven  user/  it  was  not  considered  practical 
to  expand  this  limit  on  PLATO/  instead  a  new  oata  space  called 
"storaoe"  was  introduced.  Storaoe  is  statically  allocated  for  each 
program/  hut  the  system  must  allocate  it  dynamically  to  handle 
transfers  of  control  from  one  program  to  another.  I'nlike  common  or 
user  variables/  storage  is  always  deallocated  when  the  user  leaves 
the  system. 


Storaoe  is  allocated  on  PLA10  in  ECS/  and  the  same  mapping 
mechanism  is  used  to  <',ain  access  to  it  oS  is  used  for  common 
variables.  Cn  PLATO/  all  disk  input  output  must  take  place  to  ECS 
(storaop  or  common).  Because  of  this/  the  most  frequent  use  of 
storaoe  on  PL'TO  is  for  disk  buffering;  incompatibilities  in  the 
support  of  this  will  probably  be  tolerable. 


I  aoe   1(1 


2.1  .' 


W-e  I  AHLb  SFGMb  I  1  IN;, 


As  was  previously  mentioned/  the  TUTuR  language  relies  on  the 
assumption  that  any  machinF  word  may  hold  any  data  type,  f  ven  on  a 
<Mj  (it  mac,  ine;  this  forces  great  inefficiency  in  the  storage  of 
such  thin os  as  character  strings  or  bit  arrays.  l  n  r  I  y  in  the 
evolution  of  TUTOR/  a  partial  solution  to  thit>  was  provided  by 
special  commands  that  manipulate  character  strings  oackeu  10  six  bit 
codes  per  6rJ  bit  word.  This  partial  solution  prove  '  indoequdte*  and 
a  eneral  solution  was  provided  in  the  ability  to  sec; went  blocks  of 
physical  words  into  arrays  of  smaller  logical  words. 

It  is  the  intent  of  TUTOR  that  a  reference  to  an  element  of  a 
serj'ented  array  should  be  equivalent  to  a  reference  to  a  machine 
war  ;  in  all  contexts.  F-ecause  of  the  basic  desiqn  of  the  PLATO 
implementation*  this  intent  is  not  yet  fully  supported/  but  Given 
the  forekno*ledqe  that  it  should  be/  any  new  implementation  shoula 
no    so  from  the  beginning. 

i 
?.?.     PR0C-.F''*  FEPRESFNTATTOM 


Pecause  access  to  s^omented  variables  and  integer  arithmetic 
must  both  be  subroutines  on  a  3?  or  V>  bit  machine*  ana  because 
almost  all  of  the  TUT^R  commands  are  sub  r  out  i  no -I  i  k  e  with  many 
parameters  and  complex  side  effects*  tht  time  overhead  of 
intermedial  code  interpretation  as  compared  to  direct  machine  code 
execution  should  not  be  too  excessive. 
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Execution  by  source  interpretation  would  be  prohibitive  because 
of  the  cost  of  lexical  analysis  rnd  run  time  symbol  table 
maintenance  (TUTOR  mrtkes  no  variable  print  n  me  restrictions 
analooous  to  those  of  BASIC).  Given  that  source  compression  is 
required*  compilation  of  expressions  to  postfix  form*  with 
interpretation  by  means  of  a  virtual  stack  machine  provides  an 
obvious  choice.  The  stack  in  such  a  scheme  can  also  te  useo  for 
action  routine  argument  passing  ano  for  user  procedure  linkage*  as 
well  as  for  temporary  storaoe  when  needed  by  any  of  the  action 
rout  i  nes  . 

On  the  toroet  class  of  machines*  an  right  bit  instruction 
syllable  is  reasonable*  with  16  bit  branch  and  data  address  fields. 
Because  of  the  existence  of  user*  common*  storage*  and  segmenteo 
variables*  oata  address  fields  must  also  contain  an  indication  of 
which  data  space  or  subspace  is  to  be  addressed*  as  well  as  the  word 
size  and  characteristics  of  that  space.  The  use  of  16  bit  branch 
addresses  limits  the  program  size  to  65536  bytes*  comparable  to  the 
8000  60  bit  word  limit  that  used  to  exist  on  PLATO. 


l*ost  oi  the  information  about  each  of  the  many  address  spaces 
and  segmented  subspaces  can  be  storeo  in  a  table  of  space 
characteristics.  with  this  scheme*  e  o  c  h  memory  address  must  contain 
an  index  (<  bits)  into  this  seqment  table*  *s  well  as  the  16  bit 
offset  into  the  desired  addressino  space.  It  shoulo  not  be 
difficult  to  extend  this  scheme  to  rnulti-dimensional  arrays  as  has 
recently  been  done  on  PLATu.  This  scheme  should  te  contrasted  with 
the  hardware  data  descriptor  schemes  of  some  machines  [15]. 
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The  assionment  of  values  to  entries  in  the  segment  table  would 
le  the  responsibility  of  the  compiler  if  the  PL£TO  definition  of 
TUT  R  is  retained;  however/  it  is  a  simple  extension  to  allow  run 
tinu  redefinition  of  table  entries.  Ihus/  this  nemory  addressing 
mech-nism  can  easily  be  extended  to  support  dynamic  allocation  of 
temporary  variables  on  the  stack. 

Interpretation  of  an  intermediate  code  similar  to  that  outlined 
above  can  be  quite  f3St.  The  code  accomplishing  the  action 
specified  by  any  particular  instruction  can  be  prefixed  to  code  that 
fetches  the  next  byte  from  the  instruction  stream,  increments  the 
program  counter/  and  branches  through  a  jump  table  indexed  with  the 
byte  fetched  to  the  next  action  routine  IAD. 

As  mentioned  earlier/  all  parameters  to  TUT  OK  commands  can  be 
passed  on  the  interpreter  stack.  '  iven  an  alternative  to  the  run 
time  scan  of  the  command  list  that  some  commands  require/  the 
various  commands  may  then  be  represented  in  the  intermediate  code  by 
a  trefix  byte  followed  by  an  h  bit  command  code.  This  allows  the 
definition  of  2  5  e>  commands  per  available  prefix.  Parital 
specifications  for  such  an  interpreter  are  presented  in  appendix  E i 
examrles  of  commands  compiled  into  this  code  are  presented  in 
appendix  C. 

2.3.     DATA  PfcPPESENTATION 


The  alternative  representations  tor  inteqers  have  already  been 
discussed  [section  2.1.23/  and  as  was  mentioned/  the  reasonable 
choices   are  interpretive  simulation  of  full  64  bit  integers/  or  use 
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of  •  vailable  hardware  3?  bit  integers  with  sign  extension  to  64  bits 
provided  i  nte  rpret  i  ve  I  y .  The  letter  alternative-  is  probably 
preferable  because  there  are  few  problems  requirinq  the  use  of  64 
Dit  integers*  and  the  simulation  of  multiplication  and  division  to 
the  full  precision  can  be  quite  slow.  The  PLaTO  harOware  only 
supports  int'oer  operations  for  the  *-8  least  significant  bits  of  the 
60  rit  word*  and  it  is  not  likely  that  the  the  difference  between  48 
and  32  bits  will  cause  many  problems. 

Because  of  the  practice  of  dealing  with  character  and  bit 
strirns  packed  into  words  as  integers/  the  integer  comparison  and 
bit  manipulation  operations  must  always  work  over  the  entire  word 
s  i  z  «.  . 

The  largest  remaininu  data  representation  problems  occur  with 
character  drita.  Many  programs  on  PLATO  rncke  explicit  use  of  the 
packinn  of  ten  6  bit  character  codes  per  machin<  word;  and  until 
recently*  it  was  common  practice  to  make  explicit  use  of  the 
specific  6  bit  codes  for  various  characters.  Ur  ti>e  letter  reason* 
it  has  been  suTaested  Co]  that  the  PLATO  "  bit  codes  be  preserved 
and  packed  into  machine  bytes  with  high  order  bits  unused.  Since 
that  suqqestion  was  made*  use  of  quo  to  character  literals  has  been 
stronaly  encouraged  on  PLATO*  so  any  character  set  will  trobably  be 
acceptable  as  long  as  it  is  extensive  enough. 


Thouqh  many  simple  CAI  programs  may  survive  the  change  from  ten 
6  bit  to  eiqht  M  bit  characters  per  word*  this  change  may  be 
responsible  for  the  greatest  conversion  costs  for  many  of  the  more 
interesting   programs   on  PLATO.   On  the  other  hand*  preservation  of 
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the  current  PLATO  character  set  (on  machines  with  natural  addressing 
to  t>  bit  bytes)  could  introduce  what  may  be  an  unacceptable 
execution  overhead  on  smaller  machines/  as  well  as  making  PLATO 
software  incompatible  with  other  software  already  existing  on  the 
host  machine. 


One  problem  that  may  invalidate  the  assumptions  ebout  the  use 
of  the  natural  addressing  capabilities  of  some  machines  is  that 
TUT'R  proqrrms  frequently  make  explicit  use  of  the  left  to  riyht 
storage  of  bytes  end  seqmented  variables  in  a  machine  word.  This 
will  require  interpretive  intervention  if  TUTOR  is  to  be  supported 
on  i-ny  of  the  large  family  of  machines  that  store  bytes  from  right 
to  Left  in  memory. 
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3.    JUDGING  OR  INPUT  MANIPULATION 

The  response  judging  capabilities  in  TUTOR  serve  two  separate 
purposes.  First*  they  provide  the  user  with  well  structured  access 
tc  ?.  set  of  powerful  primitives  for  requesting  terminal  input* 
rejecting  that  input*  or  requesting  that  the  input  be  modified. 
Secondly*  they  provide  access  to  a  powerful  set  of  character  string 
and  numeric  rxpression  analysis  facilities  for  the  evaluation  of  the 
terminal  input. 

The  response  judoing  subset  of  TUTOR  was  originally  conceived 
as  a  mechanism  to  be  used  for  computer  quiz  administration  or 
similar  applications  where  the  computer  would  present  a  question  and 
decide  which  of  the  responses  anticipated  by  the  program  author  most 
closely  resemble!  the  answer  aiven  by  the  user.  After  having 
decided  which  response  to  the  question  was  given*  the  program  had 
the  alternative  of  accepting  the  response  or  rejecting  it.  It  the 
response  was  rejected*  the  pro-ram  could  provide  appropriate 
feedback  to  the  user*  after  which  the  computer  would  automatically 
request  that  the  user  modify  the  response  before  re  -subm  i  1 1  i  n«i  it  to 
the  prooram. 

3.1.     THf  RFSPCNSE  JUDGING  MECHANISM 


Once  the  input  has  been  accepted  from  the  terminal*  there  are  a 
numter  of  ways  that  it  can  be  analyzed.  TUTOR  provides  analysis 
routines  that  will  compare  the  input  with  a  character  strino  for  an 
exact   match*   evaluate   the   input   as   a   simple  numeric  quantity* 
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evaluate  it  *s  an  expression/  parse  it  into  words/  or  both  parse  and 
compare  it  with  a  predefined  vocabulary  with  allowance  for  simple 
spellinq  errors. 

All  o+  these  capabilities  exist  on  other  systems/  though  it  is 
uncommon  to  find  them  all  in  one  system.  The  recuireo  analysis 
methods  are  disjoint/  and  can  be  inaividually  implemented  by 
conventional  means.  The  actual  input  analysis  mechanism  for  use  on 
a  small  machine  is  a  separate  problem  1253/  and  the  mechanism  used 
on  PLATO  hds  been  described  elsewhere  [23J.  The  input  output 
requirements  ol  TUTOR  judqino  are  considerably  more  complex  than 
conventional  unit  record  approaches  [chapter  6]/  but  the  complexity 
is  not  outside  the  range  of  adaptability  of  some  vendor  supplied 
systems  [23. 

The  remainder  of  this  chapter  deals  with  alternatives  for  the 
implementation  of  the  prooram  control  structures  defined  by  the 
TUTTiR  judging  mechanisms. 

3.2.     FFFECTS  OF  JUDGING  ON  PROGRAM  STRUCTURE 


The  control  structures  proviaed  L  y  TUTOR  tor  response  judging 
are  described  by  the  FLAfO  project  in  terms  of  a  number  of  program 
execution  states/  where  each  command  may  have  a  different  meaning  in 
p<jch  state  [11/193.  These  states  are  summarized  in  appendix  A.  The 
opscription  of  the  judiina  control  structure/  in  terms  of  execution 
states*  markers  and  searches  for  various  commands/  obscures  the 
underlying  control  structures  to  the  extent  that  most  beginning  and 
many  experienced  TUTOR  programmers  never  fully  understand  it. 
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The  KAIL  selector  [93  was  developed  as  an  alternative  syntactic 
representation  for  the  TUTOR  judaing  control  structure.  The  KAIL 
selector  actually  represents  only  some  of  the  capabilities/  with  the 
block  exit  capabilities  of  the  post  -specs-  states  not  supportea; 
however/  it  represents  an  important  step  towards  the  interpretation 
of  the  judging  mechanism  in  terms  of  traditional  control  structures. 


3.2.1 


THfc  TUTOR  JUDGING  BLOCK 


From  the  description  in  appenaix  A/  it  can  be  aeduced  that  a 
reqion  of  TUTOR  code  involvinc  judning  always  beoins  with  an 
-arrow-/  and  is  ended  by  a  new  -arrow-/  -end.irrow-/  or  -unit- 
command.  F  \ir  the  rmore/  termination  by  an  -arrow-  or  -unit-  command 
is  equivalent  to  termination  by  an  -endarrow-  immeaiately  precedinq 
the  -arrow-  or  -unit-.  Since  a  compiler  can  always  oenerate  the 
appropriate  code  for  an  implicit  -endarrow-  before  -unit-  and 
-arrow-  commands/  if  there  was  a  previous  -arrow-  command;  it  is 
safe  to  consider  judqing  only  in  tf rms  of  -arrow-  -endarrow-  pairs 
or  judging  blocks  (excluding  for  the  moment  the  problem  of 
sub  rout  i  nes )  . 


Furthermore/  the  -arrow-  is  merely  a  prefix  to  a  loop  that 
beams  with  the  first  judqing  command  after  the  -arrow-  and  ends  at 
the  -endarrow-/  with  termination  occurring  when  judginq  state  ends 
with  an  "ok"  judqment.  ^iven  the  above  observations/  an  -endarrow- 
can  be  compiled  as  a  conditional  branch  to  the  first  judginc  command 
after  the  most  recent  -arrow-/  where  the  branch  will  be  followed  if 
the  lest  juc-^ment  was  "no"  [appendix  b .  1  ]  . 
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When  subroutines  and  Local  -branch-  commands  are  included  in 
this  description/  it  becomes  much  more  complicated.  On  PLATO/  only 
mre  uses  are  made  of  the  more  pathological  interactions  between 
these  lanquaqe  components.  In  fact/  the  addition  of  a  few  simple 
rul°s  to  tfe  TUTOR  language  allows  this  simple  description  to  be 
retnined:  First  the  -endarrow-  for  each  -arrow-  must  b*>  required  to 
he  in  the  same  unit  or  proqram  segment  as  the  -arrow-.  Secondly/ 
all  simple  branches  into  and  out  of  the  ranee  of  a  judging  ulock 
must  be  forbidden.  These  rules  correspond  closely  to  the 
traditional  rules  of  structured  procrammino  where  unrestrained 
branching  is  limited/  and  control  structures  may  be  nested  but  not 
arbitrarily  overlapped. 

3.2.?.     CONDITIONS  FOR  RESPONSE  EVALUATION 


The1  judqinq  commands  in  TUTCR  fall  into  two  classes:  Those 
that  are  considered  judging  commands  because  they  require  the  input 
to  r>  e  ready  before  execution/  and  must  therefore  be  executed  in 
judging  state/  and  those  that  actually  perform  some  judgment/  ending 
the  judding  state  with  an  "ok"  or  "no".  The  judging  commands  may  be 
interspersed  with  regular  commands/  but  in  judging  state/  only  the 
jud  nnn  commands  are  executed;  th is  suqgests  linking  each  judying 
command  to  the  next  by  branches  that  are  conditional  on  judging 
state.  This  may  be  considered  to  be  merely  the  removal  of  the 
regular  commands  from  the  linked  command  list  implementation  of 
MULTTTUTOR  117/18]. 
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When  an  -endarrow-  is  encountered  in  judging  state/  the 
judoment  is  "no"/  so  the  interpretation  of  all  -endarrow-s  as  being 
preceded  by  an  implicit  -no-  command  is  safe  (the  -no-  command  is 
defined  as  always  endino  judging  with  a  "no"  judoment). 

3.2.  '.     FXECUT10N  OF  BLOCKS  CONDITIONAL  ON  JUDOMENT 

With  the  addition  of  the  branches  from  -endarrow-  to  the  first 
judging  command/  and  from  each  judginq  command  to  the  next/  it  is 
rather  easy  to  follow  through  to  the  end:  Any  judging  command  after 
the  first  one/  in  a  sequence  that  is  preceded  by  regular  commands/ 
must  be  preceded  by  a  conditional  branch  back  to  the  location  after 
any  previous  -specs-  command/  or  to  the  -endarrow-.  There  is  an 
exception  to  this  rule  when  the  previous  judging  command  was 
-specs-;  in  which  case/  the  branch  is  always  to  the  -endarrow-. 
These  branches  are  conditional  on  the  state  beinc  postjudging 
reqular/  and  they  accomplish  the  eventual  transfer  of  control  to  the 
-endarrow-  where  the  decision  is  made  whether  or  not  to  loop. 


The  maiority  of  TUTOR  judging  blocks  are  actually  quite  well 
structured.  ?hey  typically  consist  of  a  loop  terminated  by  an  "ok" 
judoment.  The  loop  contains  an  input  request  and  a  series  of  blocks 
of  rode  executed  conditionally  on  the  results  of  the  various  judging 
commands.  Appendices  D.1  and  D.?  illustrate  the  reduction  of  a 
TUT'  R  judgino  sequence  to  a  flowchart/  and  from  there  to  code  in  a 
well  structured  form.  Niote  that  the  inclusion  of  post  -specs- 
regular  commands  requires  the  use  of  Zahn's  event  driven  block  exit 
[5,12,26]  . 
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3.2.4.     JUDGING  AND  SUBROUTINE  CALLS 


One  of  the  difficulties  of  compilinq  TUT.'R  that  will  be 
oiscussed  in  more  detail  in  chapter  u  is  that  it  is  not  possible  to 
specify  that  a  unit  is  only  to  he  used  as  a  subroutine/  as  an 
extension  to  another  unit/  or  is  a  main  program/  in  fact/  it  is 
perfectly  possible  to  use  a  single  unit  as  all  three/  though  this 
may  be  considered  bad  practice. 

For  tbr  purposes  of  this  discussion/  it  is  sufficient  to  know 
that  there  are  two  types  of  subroutine  calls  in  TUTOR:  The  first  o1 
these/  the  -do-  command/  is  a  reqular  command/  and  is  the  most 
commmonly  used.  The  second  is  the  -join-  command/  this  is  ; 
somewhat  confusing  command  because  it  is  defined  as  being  executec 
in  3  L  I  of  thf>  TUTOR  execution  states. 

If   a   unit  is  entered  while  in  judqing  state  (via  -join-)/  Xhi 

search    for    a    judging  command   must   continue.   This   may   b< 

accomplished   by   following  the  unit  entry  with  a  branch  on  judoin< 

state   to  the  first  judging  command  (if  any)  in  the  unit  (to  the  en< 
of  the  unit  if  none )  . 


When  judqinq  is  ended  within  a  unit  that  has  been  attached  as  . 
subroutine  by  -join-/  control  must  somehow  return  to  the  appropriat' 
place.  In  that  the  compiler  does  not  know  how  the  unit  is  to  b 
executed/  it  will  be  attempting  to  create  a  branch  to  the  pre\/iou 
-sppcs-  command/  or  some  later  -endarrow-.  One  alternative  is  t 
define  -endarrow-  (even  if  implicit)  differently  if  it  i 
encountered  before  an  -arrow-  in  a  unit  or  if  there  is  no  -arrow-  i 
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the  unit;  the  compiler  may  then  link  all  regular  blocks  controlled 
by  juduing  commands  to  a  possibly  virtual  -endarrow-/  with  the 
appropriate  state  marker  being  set  before  the  return. 

Thr  execution  of  -join-  while  in  search  state  (that  is  while 
searching  for  the  (possibly  implicit)  -endarrow-  alter  an  "ok" 
judgment)  is  not  a  wiaely  used  feature  of  TUTOR/  ana  it  was  not 
considered  necessary  to  consider  it  here.  There  has  teen  recent 
discussion  of  eliminating  search  state  on  FLATO  and  using  a  compiled 
branch  scheme  where  each  -arrow-  would  have  a  pointer  to  its 
cor respondi no  -endarrow-  or  equivalent. 


The    problem  is   then   to   differentiate   all   the   different 

execution   states  that   may  exist  on  return  from  a  unit  ottached  by 
-join-   with   conditional   branches   to  the  appropriate  places:   One 

branch   should   be  to   the  next  judging  comnana  it  still  in  judoing 

state/   the   other  to   the   next   -enddrrow-   if   in   post  '  pseudo' 

-endarrow-   state/  and   finally   no  branch  if  in  any  of  the  regular 
states. 

3.3.     INTERPRETER  MECHANISES  AND  THE  COMPILER 


The  adoption  of  the  division  of  control  structure  semantics  and 
int°rpretation/  as  outlined  above/  provides  the  necessary 
flexibility  needed  to  support  alternate  source  languages  that  share 
the  same  execution  packaoe.  This  places  a  considerably  larger 
burden  on  the  compiler  than  the  PLATO  scheme/  but  it  broadens  the 
r  a  n  o  e  of  alternative  execution  schemes. 
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The  various  states  that  have  been  mentioned  so  far  for  judging 
purposes  may  be  reduced  to  a  4  bit  'nibble*  appropriate  tor  testiny 
with  simple  conditional  branches.  The  required  bits  are  listed  in 
appendix  B.1.1,  and  the  test  and  branch  commands  in  B.3.1.  Appendix 
D  outlines  the  compile  time  expansion  process  by  which  various  TUTOR 
commands  arr  converted  into  assortments  of  conditional  branches  on 
status^  and  calls  to  unconditional  utility  routines. 
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4.    UNITS  OP  UNIVERSAL  PROGRAM  SEGMENTS 

As  well  *s  beinu  the  basis  of  the  virtual  memory  scheme  on 
PLATO*  TUTOR  units  may  be  used  as  subroutines  by  the  -do-  or  -join- 
commands.  Units  may  also  be  attached  as  logical  continuations  of 
othor  units  by  the  -coto-  command/'  or  they  may  be  used  as  new  main 
program  segments  by  the  jump  commands  (not  only  -jump-*  but  also 
'key  arming'  commands). 

1.1.   THE  DIFFERENT  USES  OF  UNITS 

4.1.1.    AS  MAIN  PROGRAM  SEGMENTS 

A  unit  to  which  control  is  transferred  from  another  unit  by  the 
-jump-  command*  by  one  of  the  interrupt  facilities*  by  sequential 
entry  from  the  previous  unit*  or  as  the  first  named  unit  of  a  new 
program  is  executed  as  a  main  unit.  On  entry  to  a  main  unit/  the 
subroutine  linkage  stack  is  cleared*  the  screen  is  erased*  and  if 
the  feature  is  armed*  the  unit  named  as  an  'imain'  unit  is  called  as 
an  initializing  routine  by  a  call  equivolent  to  the  -do-  call. 


Tb»   most   obvious  approach  to  providing  the  special  effects  on 

entry   to   a   main   unit  is  to  implement  them  as  side  effects  of  the 

various   commands   that   can  start  main  units.   This  is  the  approach 

used    on   PLATO*   but   it   has   the   undesirable   result   that   the 

int'Tpreter   code  used  for  entry  to  a  unit  would  not  be  usable  for  a 

language   where  the  type  of  a  program  segment  is  not  bound  by  how  it 
I 
is  reached*  but  by  how  it  is  defined. 


Page   24 

An  alternative  met  bod  exists  for  the  compilation  of  main  units 
in  which  each  unit  beqir,  s  with  a  special  commanc  responsible  for  all 
of  the  side  effects  of  main  unit  entry.  All  commands  that  enter  the 
unit  as  a  main  unit  takp  the  address  of  the  side  effect  command*  and 
oil  others  (such  as  subroutine  entry  and  -ooto-)  take  the  address 
followina  it.  This  provides  for  a  complete  separation  of  the 
control  structurinn  commands  from  their  TUTOR  sicie  effects  at  the 
expense  of  one  or  two  extra  bytes  per  unit. 

Uhen  control  reaches  the  end  of  a  main  unit/  (includinc  passing 
the  implicit  -endarrow-  of  section  3.2.1)/  execution  holds  until  the 
user  directs  it  to  continue  (by  pressing  the  NEXT  key).  When  ready/ 
control  transfers  to  either  the  next  unit  in  sequence  or  to  the  unit 
specified  in  the  last  -next-  command  (if  there  was  one);  in  either 
Cose/  the  new  unit  is  entered  as  a  main  unit.  These  functions  can 
be  accomplished  by  a  special  end  unit  instruction. 


4.1  .2 


AS  SUBROUTINFS 


TUTOR  provides  two  kinds  of  subroutine  calls  which  differ  only 
in  their  relationship  to  TUTOR  judging  [section  3.2.4],  Clearly/  an 
essential  requirement  of  subroutines  is  that  they  return  when 
completed.  This  may  be  accomplished  by  having  the  end  unit  command 
(mentioned  in  the  previous  section)  execute  a  subroutine  return  if 
thp  current  unit  was  entered  as  a  subroutine;  but/  to  allow  future 
experiments  with  alternatives  to  units/  it  is  simple  to  explicitly 
compile  a  conditional  subroutine  return  just  before  the  implicit  end 
unit  comm  and  . 
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4.1.3.    AS  INTFRRUPT  PROCESSING  ROUTINES 


In  an  interactive  environments  it  is  important  to  allow  the 
user  some  way  of  easily  alterinu  the  flow  of  program  execution.  It 
is  easy  to  tfink  of  this  ability  in  terms  of  allowing  the  user  to 
interrupt  one  process  and  initiate  another/  possibly  with  a  return 
to  the  first  when  the  second  is  finished.  TUTOR  allows  a  special 
qroup  of  keys  on  the  terminal  keyboard  to  be  a  r  m  e  c1  with  unit  names 
to  provide  a  qood  approximation  of  this.  Whenever  input  is 
requested  from  the  terminal  and  one  of  these  armed  keys  is  struck/  a 
-jump-  like  transfer  of  control  takes  place  to  the  associated  unit. 


There  r  re  two  types  of  interrupt-like  tranches  allowed  in 
TUTOR.  The  first  is  simply  a  user  initiated  -jump-  which  is 
associated  with  keys  such  as  BACK  and  STOP/  and  provices  no  real 
implementation  prohlem.  The  second  type  of  interrupt  like  -jump- 
allows  a  return  to  the  point  of  interrupt  at  a  later  time.  This 
typt/  most  freauently  associated  with  the  HfcLF  and  TFRtf  keys  on  the 
keytoard/  poses  the  major  implementation  problems.  The  ideal 
behavior  of  a  HFLP  type  branch  would  be  for  the  units  attached  by  it 
to  be  executed  as  subroutines/  with  the  entire  execution  status 
beiruj  restored  on  return  to  the  point  where  the  interrupt  occurred/ 
and  with  allowance  for  nesting  of  HELP  interrupts.  Unfortunately/ 
the  status  that  would  need  to  be  saved  includes  the  entire  content 
of  the  term  i  n  a  I  display  and  input  line  editinq  buffers  at  the  time 
of  the  interrupt.  On  the  PLATO  system/  with  its  512  by  512  dot 
addressable  screen/  this  would  entail  the  storaje  of  over  256K  bits 
of  information  per  level  of  nestino. 
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The  solution  adopted  in  TUTOR*  l  reasonable  one/  is  to  return 
to  desionateo  point  before  the  point  where  the  interrupt  occurred* 
allowin-  for  the  regeneration  of  the  screen  contents  and  for  the 
reinitiation  of  any  input  transaction  that  may  have  been 
interrupted.  The  restart  point  in  TUTOR  is  the  start  of  the  most 
recent  main  unit  entered  (called  the  base  unit).  when  a  HELP  type 
branch  occurs*  the  BACK  key  ir,  armed  in  the  new  main  unit  to  jump 
bock  to  the  base  unit. 

TUTOR  does  not  allow  true  nest ino  of  HELP  sequences*  rather*  it 
allows  the  arminq  of  the  HELP  key  within  such  sequences  to  branch  to 
new  -help-  sequences  without  chanqinu  the  base  unit  pointer.  Thouqh 
the  base  pointer  may  be  manually  cleared  or  set*  it  is  normally 
cleared  by  followinq  the  specially  armed  BACK  branch. 

Tht  recent  addition  of  the  -helpop-  mechanism  to  the  repertory 
of  TUTOR  key  arminq  commands  poses  different  implementation 
prorlems.  H"~re*  subroutine  like  unit  attachment  occurs  when  an 
-'op-  typp  key  is  pressed*"  except  that  the  -'op-  unit  returns  to  the 
point  just  before  the  command  which  was  interrupteo*  and  a 
siqnifiqant  amount  of  judqinq  state  information  is  saved  if  an  -'op- 
unit  is  activated  within  a  judqing  sequence. 


The  PL '"TO  mechanism  for  supporting  TUTOR  -help-  type  branches 
nnd  returns  i  nvolves  tne  use  of  two  pointers*  one  to  the  current 
main  unit  entry  [;oint*  and  one  to  the  current  base  unit.  This 
scheme  is  not  only  adequate  for  a  small  machine  implementation*  but 
easily  lends  itself  to  experimentation  with  nestinq  of  interrupts  by 
savin q  and  restorinq  the  base  unit  pointer  durinq  procedure  linkage. 
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4.1.  4.     AS  CONTINUATIONS  OF  OTHER  UNITS 


Thp  -ooto-  command  in  TUTOR  simply  transfers  control  to  the 
named  unit  without  any  change  to  any  of  the  program  status* 
includino  memory  of  the  location  of  the  previous  -arrow-  (if 
present).  The  resultant  interdct ion  of  -goto-  with  the  judging 
mechanism  includes  such  thinqs  as  returns  to  the  last  -arrow-  and 
state  changes.  Because  of  these  pathological  cases/  -tioto-  poses 
problems  to  a  new  TUTOR  implementation. 

The  -goto-  command  is  incompatible  with  the  compilation  of 
branches  proposed  in  chapter  7>  as  a  solution  to  implementing  TUTOR 
judging  sequencing.  Fortunately/  the  use  of  this  aspect  of  the 
TUTOR  lanauaae  is  not  encouraqed/  is  it  is  difficult  to  explain  the 
unexpected  results.  Because  of  this/  and  in  keeping  with  the  rules 
mentioned  in  section  3.2.1/  the  use  of  -joto-  from  within  judging 
sequences  may  bp  forbidden  (in  almost  all  cases/  -do-  can  be  used  to 
achieve  the  same  function  much  more  clearly). 

4.2.     FARAMTFRS  TO  UNITS 


Somewhr-t  late  in  the  history  o  ♦  TUTCR/  in  f  ,  c  t  after  much  of 
the  initial  work  on  this  project  hao  been  complete  d  /  the  ability  to 
pass  parameters  with  any  direct  control  transfer  to  a  unit  was 
introduced.  Previous  programming  :  ractice  in  TUT(R  hod  generally 
included  the  allocation  of  fixed  -j  roups  of  user  variables  to  each 
unit  that  needed  parameters/  and  then  assigning  values  to  each 
parameter  before  each  call.  When  the  passing  mechanism  was 
introduced/   it   was   made  completely  compatible  with  that  approach; 
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that   is/   parameters  in  TUT^R  involve  no  temporary  storage  or  local 

variables  . 


fnven  c  stack  based  interpreter/  the  obvious  implementation  is 
to  push  all  of  the  parameters  onto  the  stack  before  a  call  and  pop 
them  into  the  appropriate  locations  after  entry  into  the  new  unit. 
There  are  two  complications  to  this  scheme:  One  involves  main  unit 
entry  which  must  pop  the  subroutine  linkage  stack;  the  other 
involves  thp  fact  that  with  any  call/  a  subset  of  the  parameter  list 
may  be  passed  with  only  the  corresponding  locations  being  changea  in 
the  called  routine/  the  other  parameter  locations  retaining  their 
previous  contents. 

Because  parameters  may  be  passed  not  only  with  -do-  -join-  and 
-qoto-  but  also  with  -jump-  and/  with  trivial  extensions/  -nextnow-/ 
the  first  problem  occurs.  If  parameters  are  passed  on  the  stack/  , 
the  commands  that  start  a  new  main  unit  must  then  copy  any  parameter 
t' lock  down  the  stack  when  they  undo  the  procedure  linkage.  This 
requires  that  a  count  of  the  n umber  of  parameters  be  stored  above 
the  parameters  on  the  stack.  The  count  must  be  on  the  stack  because 
the  'imain'  unit/  if  present/  will  be  done  by  the  begin  main  unit 
command  before  the  code  to  resolve  the  parameters. 

The  second  problem  may  be  solved  ry  passing/  as  an  additional 
parameter/  a  bit  vector  indicatina  which  parameters  are  present. 
Thii  bit  vector  must  also  oive  the  types  of  each  parameter  (integer 
or  floatinq)  because  TUTOR  performs  automatic  conversion  of 
parameter  types/  and  the  requirements  of  fast  compilation  preclude  a 
nlobal   first   pass   to   work  out  the  types  expected  with  each  unit. 
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Given  a  64  bit  wide  stack  and  usinq  2  bits  for  each  parameter/  while 
reserving  8  bits  tor  the  previously  mentioned  count/  a  total  of  2b 
parameters  may  be  passed. 

This  scheme  is  compatible  with  the  eventual  implementation  of 
temporary  local  data  allocation  tor  units  using  the  single  stack. 
The  same  calling  sequence  would  be  used/  while  the  receiving 
sequence  could  set  up  some  special  segmented  variable  [section 
2.1. SI  to  a  1 1 o  w  addressino  of  the  parameter  list  ana  new  local 
storage  instead  of  copying  the  parameters  into  fixed  locations. 

4.3.     INTERPRETER  MECHANISMS  AND  THE  COFPILtk 

4.3.1.     PROGRAM  STATUS  INFORMATION 

The  unit  sequencing  mechanisms  outlined  above  require  that  the 
prooram  status  contain  at  least  i  main  and  base  unit  pointer/  and 
thrfp  more  status  bits  that  may  be  tested  in  a  manner  similar  to 
those  used  for  judging.  One  status  bit  would  re  requirea  for  the 
parameter  parsing  mechanism/  indicating  that  parameters  exist  on  the 
stack  and  must  be  stored.  The  second  status  bit  indicates  that  the 
current  unit  is  beinc  executed  as  an  attached  unit  by  -do-  or 
-join-.  The  third  bit  is  needed  to  differentiate  -help-  from 
-help op-  type  unit  attachment  when  the  base  pointer  is  non  zero. 


Tn  addition  to  this/  the  program  status  must  contain  space  for 
a  return  address  for  -do-  and  -join-/  and  somf  mechanism  for  nesting 
these  calls.  The  minimum  information  that  must  be  saved  for  nested 
calls   consists   of   the   return   a i dress   and  parameter  status  bit. 
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Saving  and  restorina  the  other  linkage  bits  would  not  cause 
conflicts/  hut  the  judoinq  status  hits  must  not  be  saved  and 
restored^  as  they  are  used  to  return  results  of  judging  operations 
in  joined  units.  Saving  and  restoring  the  base  pointer  would  allow 
future  experiments  with  -help-  type  interrupt  nesting  without 
conflicting  with  the  current  TUTOR  definition. 

The  use  of  a  single  stack  for  the  return  linkages  as  well  as 
intermediate  results/  parameters/  loop  control  blocks/  and  future 
procedure  local  variables  requires  that  the  program  status  also 
contain  a  special  linkage  pointer  to  the  previous  program  status 
block  on  the  st?ck. 


A. 3  .2 


STANDARD  CALLING  AND  RECEIVING  SEQUENCES 


The  actual  call  generated  by  a  -do-  or  -join-  command  must 
consist  first  of  reserving  space  on  the  stock  for  linkage/  then 
placing  the  optional  parameters  on  the  stack/  followed  by  the  bit 
vector  qiviria  the  count/  types  and  positions  of  the  parameters. 
After  this  comes  the  actual  subroutine  call  or  branch  which  must 
have/  as  in  line  arguments/  both  the  address  of  the  unit  to  be 
executed  and  a  parameter  presence  indicator  (so  that  the  linkage  can 
be  correctly  placed  in  the  stack). 

If  a  unit  expects  parameters/  it  must  begin  with  a  branch 
coniitional  on  their  absence  around  the  parameter  recieving  code. 
The  parameter  recievinq  code  consists  first  of  the  computation  of 
all  of  the  addresses/  followed  by  the  execution  of  the  parameter 
resolution   command   which   stores  values  in  addresses  with  optional 
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float inq  or  fixing  (as  indicated  by  the  parameter  presence  bit 
vector  and  the  type  information  supplied  as  part  of  the  addresses). 
The  process  of  parameter  resolution  pops  the  values  and  addresses/ 
which  is  why  the  linkage  must  be  stored  below  the  parameters  on  the 
stack.  At  the  end  of  each  unit/  after  the  (possibly  virtual) 
-endsrrow-/  a  return  must  be  inserted  conditional  on  the  subroutine 
status  bit. 
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TUTOR  CONDITIONAL  AND  LOOPING.  COMMANDS 


All  but  the  most  trivial  of  programs  must  make  choices  am 
repeat  various  sections  of  code.  TUTOR  provides  a  number  o 
mecr^nisms  for  this/  ranginq  from  simple  conditional  branch  command 
to  conditional  and  looping  variants  of  other  commands. 

5.1.   CONDITIONAL  COMMANDS 

A  large  number  of  commands  in  TUTOR  have  conditional  variant 
in  which  the  command  is  executed  with  respect  to  one  of  a  group  o 
parameter  lists  dependent  on  an  integer  selector  value.  Command 
with  conditional  variants  include  flow  of  control  commanos  such  a 
-branch-/  -^oto-/  and  -do-;  key  arming  commands  such  as  -help- 
display  aeneration  commands  such  as  -writec-;  and  computations 
commands  such  as  -calcc-  and  -calcs-.  There  may  be  any  number  o' 
choices  in  these  conditional  forms/  the  first  one  being  selecte 
when  the  selector  is  neoative*  the  second  on  zero/  the  third  on  one 
and  so  forth. 


These  conditional  variants  spread  to  a  large  number  of  TUTO 
commands  at  a  time  when  they  were  the  only  control  structure 
allowed  within  the  body  of  a  unit  besides  those  associated  wit 
judging  and  subroutine  calls.  On  P14T0/  the  conditional  and  simpl 
form l  of  a  command  ore  not  compiled  into  variants  of  the  sam 
intermediate  code  command/  but  into  different  intermediate  com mane 
which  need  not  have  related  interpretations. 
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It  would  qreatly  simplify  the  interpretation  process  if  the 
conditional  aspects  of  a  command  were  compiled  so  that  all  commands 
would  have  a  fixed  format  from  the  point  of  view  of  the  interpreter; 
this  requires  that  there  be  a  compiler  generated  directive  for 
selecting  from  a  list  of  commands  and  parameter  lists.  This  is 
analogous  to  the  way  -case-  statements  are  handled  in  many  languages 
with  a  branch  indexed  through  a  table.  Appendix  C.3  contains  an 
example  of  the  expansion  of  a  typical  TUTOR  conditional  in  terms  of 
the  instruction  set  of  appendix  F. 

5.2.   LOOPING  COMMANDS 

The  looping  variants  of  the  -do-  and  -join-  subroutine  calls  in 
TUTOR  were/  for  a  long  time*  the  only  way  that  a  block  of  code  could 
oe  repeated/  except  by  the  use  of  conditional  -noto-  or  -jump- 
commands.  These  looping  variants  take  an  incex  variable*  initial 
value/  final  value/  <jnd  step  si/e/  and  may  either  increment  or 
decrement  the  index  variable.  If  the  looping  <*nd  conditional 
capabilities  are  used  at  the  same  time/  the  loop  then  includes  the 
conditional  list  of  units  within  it. 


As  with  the  conditional  commands/  PLATO  implements  these 
looping  variants  as  distinct  intermediate  code  commands.  Again/  to 
simplify  interpretation/  the  alternative  of  compiling  the  loop  into 
a  test  and  branch  instruction/  a  simple  command/  and  an  increment 
^nd  branch  back  instruction  is  preferable.  The  TUTOR  loops  all  are 
defined  as  looping  zero  or  more  times/  so  there  must  be  a  pre-loop 
check  instruction  as  well  as  a  post  loop  increment  and  branch. 
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On  PLATO*  the  increment  value  and  bounds  may  be  arbitrary 
expressions/  end  they  may  be  changed  during  the  execution  of  the 
loon.  Execution  of  the  loop  control  commands  may  be  considerably 
simplified  if  these  values  are  fixed  once  the  loop  is  entered/  so 
that  they  ore  calculated  only  once/  and  soved  on  the  stack  during 
looj  execution  (allowing  nestinq  of  loops).  This  incompatibility 
should  not  introduce  too  many  prohlems  because  most  applications 
make  no  use  of  the  variable  increment  *  n  d  bounds/  and  those  that  do 
may  be  easily  r  eprograrrmed  with  the  -loop-  instruction  ^roup.  The 
instruction  set  of  appendix  P. 3.1  lists  the  'precheck'  and 
•postincex'  instructions/  and  an  example  of  the  expansion  of  a  TUTOR 
looi  inn  instruction  is  niven  in  appendix  C.4. 

5.3.   LOCAL  CONTROL  STRICTURES 

Commands  for  building  control  structures  within  the  confines  of 
a  single  unit  were  introduced  somewhat  late  in  the  history  of  TUTOR. 
These  commands  are  now  generally  useable  though  they  were  originally 
limited  in  scope  to  single  extended  -calc-  statements.  Structured 
flow  of  control  commands  have  recently  been  introduced  into  TUTOR/ 
and  these  may  be  easily  compiled  into  the  simple  commanos  listed 
here. 


Th^   -do to-   command   provides   the  looping  ability  of  -do-  and 

-join-   while  repeating  an  arbetrary  group  of  commands.  These  loops 

mcy   be  nested  and  may  contain  -branch-  commands  to  exit  the  loop  on 
exceptional  conditions. 


Paqe   35 

The  -branch-  command  and  its  conditional  variant  allow  transfer 
of  control  to  an  arbitrary  label  in  a  unit.  If  the  -doto-  command 
is  implemented  with  the  use  of  the  loop  control  block  and  commands 
previously  mentioned  [section  5.2D/  special  provisions  must  then  be 
made  for  the  interaction  of  branches  with  loops. 

H ranches  into  the  range  of  a  loop  can  be  prohibited  with  few 
ill  effects  on  program  transferability.  branches  out  of  a  loop  must 
remove  the  loop  control  block  from  the  stack  before  exiting/  thus 
requiring  a  stack  modify  instruction.  With  this  scheme/  branches 
must  pop  all  loop  control  blocks  from  the  stack  before  branching/ 
and  all  labels  inside  loops  must  recover  them.  This  is  tecause  the 
compiler  Con  not  easily  determine/  when  generating  code  for  a 
branch/  whether  or  not  a  loop  exit  is  involved.  Appendix  C.4 
contains  an  example  of  this. 

5.4.   INTTRPRFTFR  MECHANISMS  AND  THE  COMPILED 


The  approach  outlined  above  allows  the  compiler  to  separate  the 
control  structures  fron  the  other  components  of  t  h  t.<  language.  This 
is  important  because  it  not  only  eliminates  redundant  interpreter 
mechanisms  but  allows  for  the  implementation  fo  alternate  languages 
with  other  control  structures  under  the  same  interpreter. 
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6.   TFRMNAL  INPUT  AND  OUTPUT 

One  of  the  most  unique  aspects  of  the  PLATO  environment  is  that 
all  of  the  terminals  are  qraphics  oriented/  with  excellent 
peripheral  support  tor  user  interaction.  The  TUTOR  language  evolved 
in  this  environment.  recause  of  t h i s /  the  input/output  features  of 
the  lanouaue  differ  in  many  ways  from  those  devised  for  batch  card 
or  teletype  oriented  systems. 

The  PLATO  IV  terminal  supports  no  natural  unit  record  such  as 
the  line  or  paqe  for  output;  because  of  this/  TUTOR  must  use  stream 
output  formatting  commands.  A  wife  variety  of  these  are  provided/ 
including  a  set  of  graphics  utilities  th.it  provide  tor  rotation  and 
scale  modification  of  line  drawn  figures  and  text. 

TUTOR  provides  two  classes  of  terminal  input  management 
facilities  which  are  both  somewhat  record  oriented.  For  simple 
input  operations/  a  fixed  record  size  of  one  or  more  characters  or 
external  input  codes  is  supported/  with  no  features  outside  the 
capabilities  of  conventional  unit  record  processing.  Commands  that 
manipulate  such  simple  input  include  -pause-  and  -collect-  as  well 
is  certain  control  structure  side  effects  such  as  those  associated 
with  the  -unit-  command  [section  4.1.1]. 


The-  most  complicated  input/output  capabilities  of  TUTOR  are 
associated  with  the  input  judging  mechanism.  here/  input  is 
initiated  hy  the  first  judging  commano  after  the  -arrow-  Csectior 
3.1/   appendix   A]  with  a  number  of  state  variables  changing  exactly 
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how  that  input  is  collected.  The  input  record  is  a  line  or  block  of 
text;  however*  many  unconventional  input/output  operations  may  be 
performed  with  respect  to  these  records. 

6.1.  THE  PLATO  IV  TFRMINAL 

All  TUTOR  terminal  input/output  is  defined  in  terms  of  the 
PLATO  IV  terminal  [20].  This  terminal  has  a  512  by  512  dot 
addressable  screen*  with  an  8  by  16  character  matrix  giving  32  lines 
of  64  characters  on  the  screen.  The  terminal  has  a  programmable 
character  set  in  addition  to  the  usual  hard  wired  one;  it  also  has 
dot  and  vector  generation*  with  the  ability  to  selectively  write  and 
erase  individual  dots*  vectors*  or  characters. 

Thp  MULTITUTOR  system  [18]  supports  *  number  of  other  terminal 
types.  The  experience  jained  on  that  system  indicates  that 
conversion  of  pro i rams  to  use  2k  line  by  80  character  alphanumeric 
CRT  terminals  is  not  an  unreasonable  task.  The  most  important 
terminal  characteristic  required  for  the  support  of  many  TUTOR 
programs  appears  to  be  a  character  addressable  terminal  with  the 
ability  to  selectively  erase  or  modify  the  aisplay  contents  on  a 
character  by  character  basis. 

6.2.  TUTOR  SUPPORT  OF  THE  TERMINAL 
6.2.1.   OUTPUT  CAPABILITY 


TUTOR'S  output  facilities  m^y  be  divided  into  three  categories: 
Those  of  text  output*  graphics  output*  and  special  device  output. 
Text   is   normally   sent   straight  to  the  terminal  with  only  minimal 
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system  intervention^  except  in  the  trucnation  of  overlenuth  lines 
and  the  establishment  of  a  left  margin.  Before  sending  text  to  the 
screen/  the  program  must  specify  where  on  the  screen  the  text  is  to 
be  shown/  in  turn/  the  system  maintains  information  so  that  the 
program  may  always  determine  the  location  of  the  last  character 
d  i  sp  I  ayed  . 


TUTOR  allows  all  display  coordinates  to  be  specified  either  as 
character  and  line  numbers  (coarse  arid)  or  as  dot  coordinates  (fine 
orii).  It  would  greatly  simplify  interpretation  if  all  commands 
could  be  defined  only  in  terms  of  one  coordinate  system.  To  allow 
for  this/  the  interpreter  contains  an  instruction  for  coordinate 
conversion   from  coarse  to  fine  arid  [appendix  f.3.?3.   The  compiler 

is   then   responsible  for  inserting  this  conversion  instruction  when 

i 

the  source  program  uses  coarse  grid. 

Text  output  from  TUTOR  may  optionally  be  converted  to  line 
drawn  output  by  the  use  of  either  system  or  user  defined  'linesets.' 
The  line  orawn  text  is  processed  through  the  graphics  output 
packaqe/  thus  allowing  the  text  to  be  rotated  and  its  size  changed 
relative  to  an  arbitrary  origin. 

The  graphics  output  capabilities  of  TUTOR  range  from  simple 
plotting  of  points  and  lines  between  absolute  physical  screer 
coordinates  to  a  qeneral  two  dimensional  qraphics  ability.  Thi? 
includes  th(  ability  to  display  complex  figures  with  respect  to  c 
logical  origin*  and  to  scale  and  rotate  these  figures  for  display 
The  ability  to  display  qraphic  information  through  a  window  or  masl 
is  also  included. 


i 
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In  addition  to  the  above/  TUTOR  allows  program  access  to  the 
writable  dot  matrix  character  set/  as  well  as  other  PLATO  terminal 
parts  such  as  a  rear  projection  slide  selector  and  audio  response 
unit.   Support  of  these  features  should  pose  no  new  problems. 

6.2.2.   SINGLf-  KEYSTROKF  INPUT 

The  -pause-  command  in  TUTCR  provides  the  basis  for  all  single 
keystroke  processing  on  PIATO.  The  -pause-  command  has  two  special 
capabilities  that  make  it  more  than  just  a  stream  input  instruction: 
First/  it  provides  the  ability  to  set  a  timer  on  the  input  so  that 
the  program  will  resume  on  either  timer  expiration  or  a  keystroke  at 
the  terminal/  where  the  data  returned  to  the  program  inoicates  how 
the  -pause-  ended.  Second/  it  is  possible  to  specify  which  inputs 
will  he  accepted  and  which  iqnored  hy  a  -pause-  command. 

The  inf. ut  filterino  capabilities  of  the  -pause-  command  are 
easily  implemented  at  the  interpreter  level  by  a  simple  'loop  until 
valid  input'  which  is  calls  on  a  simple  stream  input  routine.  The 
timp  limit  on  input  is  more  difficult/  requiring  interaction  between 
two  different  and  normally  disjoint  operating  system  components;  in 
sorti'  systems  this  may  require  sionificant  system  level  chances. 


Other  TUTOR  commands  may  re  defined  in  terms  of  -pause-/  such 
as  -collect-/  which  is  equivalent  to  a  loop  with  a  counter  and 
-pfcuse-  in  it;  or  the  -nextnow-  and  -unit-  commands/  which  are 
?quivalent  to  -jump-  commands  preceded  by  -pause-  commands  with  only 
the  NEXT  key  armed  as  a  valid  input.  Given  a  working  -pause- 
nec^-inism/  it  should  be  simple  to  implement  these  commands. 
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6.?. 3.   TEXT  INPUT  FOR  JUDGING 

There  ere  four  aspects  of  TUTOR  text  input  that  go  beyond  the 
norm-'l  unit  record  capabilities.  The  first  of  these  is  an  extension 
to  the  normal  input  line  editing  capability  that  is  present  in  some 
form  on  most  interactive  systems  (backspace  keys  etc).  Whenever  a 
TUTOR  pronrnm  expects  a  line  of  input/  it  is  possible  to  specify  a 
text  buffer  from  which  that  line  may  be  constructed  by  copying 
characters  or  words  interspersed  as  necessary  with  the  new  input. 
This  facility  allows  simple  but  powerful  text  editors  to  be 
constructed/  as  well  as  allowin  CAI  material  to  briny  up  old 
student  responses  to  be  modified  for  re -subm i ss i on . 


The  second  important  text  input  capability  required  is  the 
ability  of  a  program  to  examine  the  contents  of  the  input  buffer  and 
perform  extensive  computations  while  still  allowing  the  input 
operction  to  be  resumed  at  a  later  time.  The  prooram  may  even 
oenerate  output  and  make  use  of  the  sinole  keystroke  input 
facilities  while  some  text  input  operation  is  suspenaed.  This 
capability  is  require d  by  the  judging  mechanism  Csection  3.2.1/ 
appendix  AD/  where  the  same  input  line  may  be  repeatedly  modified 
and  reentered  tor  judgment  until  it  is  judged  "ok". 


If  output  is  venerated  between  a  temporary  termination  and  the 
reooeninn  of  an  input  request/  th*  output  must  he  erased  from  the 
screen  in  the  process  of  backtracking  to  the  state  that  existed 
before  the  temporary  input  termination.  On  PLATO/  it  was  decided 
that  total  erasure  of  anything  written  was  infeasible/  so  only  the 
last   -write-   or   other   output  command  is  erased  by  the  system/  an 
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-er,seu-   unit   may  also  be  armed  to  be  attached  as  if  by  -do-  after 
the  automatic  erasure  so  that  the  program  may  dc  the  rest  if  needed. 

The  above  PLATO  solution  is  good  enough  that  the  -eraseu- 
mecnanism  is  rarely  needed/  therefore*  incompatibility  here  can 
probably  be  tolerated.  For  instance/  an  alternate  solution  would  be 
to  erase  the  most  recently  displayed  N  characters  after  the 
termination  of  the  most  recent  input  operation;  if  N  is  large 
enouoh/  few  programs  would  be  effected.  This  alternate  approach  has 
the  advantaae  of  enforcing  a  separation  between  the  source  language 
control  structures  and  the  input  management  system  software. 

The  last  important  capability  of  TUTOR  text  input  is  that  the 
user  may  specify  and  chanqe  the  internal  code  sequences  associated 
with  the  keys  on  the  terminal  keyboard  ('micro'  substitution).  This 
ability  should  be  considered  a  function  of  the  terminal  or  the 
device  driver  rather  than  the  interpreter. 

6. 2. A.   RTSPCNSF  TIMF 


The  facilities  listed  above  could  easily  be  supported  at  the 
interpreter  level  usinu  the  sinole  character  input  mechanism  of  the 
-pause-  command.  With  many  operatino  systems/  this  would  require 
separate  transactions  for  the  receipt  of  ore  character  from  the 
keyboard  and  for  its  subsequent  display  on  thf  screen.  If  these 
transactions  are  scheduled  at  the  s  «  m  e  priority  level  as  user 
computation/  the  system  response  time  may  be  unacceptable. 


Facie  U£ 

A  preferable  alternative  would  be  to  place  the  line  editing 
functions  at  a  hioh  priority  as  a  distinct  task*  or  even  at  a  direct 
interrupt  priority  level.  This  solution  requires  that  soire  way  be 
found  to  communicate  all  of  the  desired  information  between  the 
interpreter  and  this  hioh  priority  task.  The  best  approach  would  be 
to  use  some  extension  of  the  input/output  protocols  supported  under 
the  host  operatinq  system  (for  instance  the  UNIX  'pipe'  facility 
{16}.) 

6.3.   UNIFORM  INTERNAL  CHARACTER  CODE  POSSIBILITIES 

One  problem  with  PLATO  input/output  is  caused  by  the  six  bit 
character  code  that  is  used  for  internal  text  representation.  This 
internal  code  uses  two  prefix  codes  (ACCFSS  and  SHIFT)  to  represent 
the  entire  character  s^t  used  on  PLATO;  this  causes  difficulties  in 
conjunction  with  the  -pause-  commanu  because  one  keypress  or 
external  input  from  the  terminal  may  not  generally  be  represented  as  i 
one  internal  character  code. 


On  PLATC/  the  result  is  that  the  PAUSE  command  returns  the  last 
input  in  a  different  character  code  from  the  one  used  internally. 
It  would  seem  preferable  to  use  a  sinnle  universal  character  code 
for  both  i'-put  and  output;  however*  software  character  code 
conversion  would  be  required  because  the  PLATO  terminal  itself  does 
not  use  such  a  code.  Conversion  would  be  required  on  both  input  and 
output  if  the  internal  code  is  to  be  some  extension  of  ASCII.  These 
conversions  should  be  put  in  the  line  editing  mechanism*  or  even 
closer  to  the  terminal  [223. 
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The  introduction  of  a  new  universal  character  code  will 
introduce  some  incompatibility  in  the  handling  of  external  device 
end  touch  panel  input  because  these  must  still  ce  manipulated  as 
explicit  bit  patterns  on  PLATO.  However/  the  advantages  of  these 
chanqes  seem  to  outweigh  the  problems  in  the  long  run. 

6.4.  P0SS13LTTIES  OF  SUPPORTING  OTHER  TERMINALS 

The  use  of  an  ASCII  compatible  character  set  opens  the  way  for 
support  of  m^ny  other  types  of  terminals.  Support  of  terminals  with 
only  a  subset  of  the  PLATO  capabilities  would  require  filtering  of 
output  in  order  to  eliminate  functions  that  are  not  supported;  this 
filtering  process  may  be  either  an  interpreter  function/  in  which 
case  the  interpreter  must  always  be  aware  of  the  terminal 
characteristics*  or  a  function  of  trie  output  driver. 

It  is  even  more  important  to  consider  future  support  of  the 
various  microprocessor  based  •  i nt e  1 1 i oent ■  terminals  that  are  now 
proliferating  since  these  should  be  able  to  support  many  if  not  all 
of  the  functions  of  the  PLATO  terminal.  Furthermore/  the  character 
set  and  transmission  protocols  of  such  terminals  are  all  under 
internal  sortware  control  and  should  be  matched  easily  with  any  host 
system  [ ? 1 D  . 

6.5.  DIVISION  OF  INPUT/OUTPUT  RESPONSIBILITIES 


because  of  the  above  considerations/  the  following  breakdown  of 
responsibility  for  input/output  seems  best/  and  is  the  one  that  was 
implemented.   The   way   that  linesets  and  micro  tables  are  supported 
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is  not  covered  here  because/  like  common  variables/  the  way  that 
they  are  supported  is  highly  dependent  on  the  facilities  the  host 
hardware  and  operating.  system  provides  for  inter  task  sharing  of 
info  rmat  i  on  . 

6.5.1.   THF  INTERPRETER 


Thp   interpreter  is  responsible  for  formatting  output  into  dot/ 

line/   positionino/   and   text   generation   commanas.   Communication 

between  the  interpreter  and  the  terminal  control  program  takes  place 

i 
via  packed  buffers.   On  input/  these  contain  either  unit  records  for 

■ 

juduing  or  single  characters  for  the  -pause-  family  of  commands.  On 
output/  the  buffers  contain  either  packed  data  for  display  on  the 
screen/  or  data  to  modify  future  transactions  as  interpreted  by  the 
device  handler.  These  buffers  are  passed  to  the  virtual  device 
support  pro cram  under  the  input/output  protocols  of  the  host 
operatina  system. 


6.5.2.   THF  VIRTUAL  DEVICE  HANDLER 


The  virtual  device  handler  is  a  piece  ot  software  that 
communicates  with  the  interpreter  or  other  user  level  programs  via 
the  system  supported  input/output  buffer  passing  mechonism.  It  is 
responsible  for  character  code  translation/  input  line  editing/  and 
key  echoing/  as  well  as  the  filtering  of  terminal  output/  and  input 
timer  maintenance. 
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appendix  E  outlines  the  buffer  types  and  message  meanings  to 
which  the  handler  must  respond/  as  well  as  an  appropriate  extension 
of  ASCII.  If  the  -size-  and  -rotate-  directives  are  to  apply  to  the 
echoing  of  keyset  input  during  line  editing*  the  entire 
responsibility  for  handling  these  should  ttien  be  placed  in  the 
virtual  device  handler  instead  of  the  interpreter-  This  is 
reasonable  because  these  are  logical  functions  of  future  intelligent 
terminals  . 


From  the  point  of  view  of  the  interpreter/  the  virtual  device 
handler  and  the  terminal  are  equivalent.  because  of  this/  it  is 
proper  to  consider  the  interpreter  as  beinn  written  assuming  an 
idecl  intelligent  terminal.  To  date/  virtual  device  handlers 
compatible  with  the  interpreter  have  been  written  to  handle  two 
different  terminals.  A  PLATO  IV  terminal  has  beer,  supported  using 
landler  software  which  is  distributed  between  the  mainframe  and  a 
remote  microprocessor  used  for  code  translation  [2/223.  Simple 
/ideo  CRT  terminals  with  no  graphics  capability  have  also  been 
.upported  [?]. 


Page   46 


7.   CONCLUSION 

An  interpreter  was  i mp  lement ed  on  the  basis  of  the 
considerations  outlined  here.  A  medium  scale  machine  with  a  maximum 
memory  capacity  of  one  million  8  bit  bytes  was  used.  This  machine 
has  a  virtual  memory  mechanism  based  on  ?56  word  panes  and  a  nominal 
word  size  of  16  bits*  though  the  instruction  set  allows  direct 
addressing  end  manipulation  of  bits*  bytes/  woras/  doub  I  e-wo rds  /  and 
quad-words . 

The  interpreter  was  written  to  take  advantage  of  machine 
facilities  for  reentrant  coding/  ano  has  been  tested  with  four 
simuldtneus  users  sharinq  it.  The  virtual  memory  mechanism  has  not 
yet  been  exploitec  to  its  fullest  extent/  but  it  is  anticipated  that 
support  of  demand  paging  of  user  programs  shoula  be  possible. 

7.1.   IMPLEMENTATION  RESULTS 


Bench-marks  run  on  the  interpreter  indicate  that  it  can  support 
17  compute-bound  users  with  the  same  response  characteristics  as 
provided  by  PLATO  for  similar  compute-bound  foreground  users  durino 
prime  time  (with  about  315  users).  Using  the  assumption  that  no 
more  than  half  of  the  users  will  be  compute-bound  at  any  time/  a 
system  basec  on  this  interpreter  should  be  able  to  support  about 
thirty  on-line  users  at  a  time. 
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The  problem  of  core  sharing  becomes  critical  if  thirty  users 
are  to  be  supported  on  such  a  system.  A  compact  user  program 
representation  will  si qni f i cant ly  reduce  the  swapping  or  page  fault 
overhead*  and  if  the  interpreter  can  be  made  to  run  without 
significant  overlay  use/  the  load  on  the  backing  store  will  be 
reduced  even  further.  The  performance  of  the  interpreter  is  highly 
encouraging  with  respect  to  these  considerations. 

The  previously  published  estimatesCoD  concernino  the  storage 
requirements  of  a  small  computer  based  PLATO  like  system  are 
considerably  greater  than  the  requirements  experienced  here  (both 
for  the  user  program  and  for  the  interpeter).  The  previous 
estimates  were  based  on  extrapolation  from  the  PLATO  implementation. 
The  elimination  of  redundant  mechanisms  in  the  interpreter  as 
outlined  here  is  responsible  to  a  great  extent  for  these  savings. 

The  interpreter*  as  currently  implemented*  supports  around  125 
TUTOR  commands*  as  well  as  their  conditional  and  looping  variants, 
the  support  of  these  commands  requires  1 1  0  0  h  16  Lit  words  of 
reentrant  program  space  as  compared  with  the  previous  estimate  C 63 
of  18000  16  Lit  words  to  support  only  the  20  most  frequently  used 
commands*  with  overlay  processing  being  used  for  the  remainder. 


Aside   from   the  timing  benchmark  already  mentioned*  six  PLATO 

TUTOR    lessons    have  been   transferred   from   PLATO   to   the   new 

interpreter.   For   one  lesson   transferred   C  '  a   oame   of  b0%    by  R. 

Blomme]   the   compiled  code  required  9500  h  bit  bytes  versus  2000  60 

bit   words   on   PLATO*  a  savings  of  37%.   Another  lesson  ['Receptor 

Site   Interaction'   by  R.   buzdorD  required  22718  bytes  versus  3172 
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PLATO  words*  a  savings  of  only  4%.  The  first  example  consists 
largely  of  pure  computational  code  while  the  second  consists  largely 
of  textual  material  being  presented  in  the  traditional  programmed 
learning  fas  Hon. 

7.2.     INCOMPATIBILITIES  WITH  PLATO 

The  interpreter  desion  proposed  here  is  not  fully  compatible 
with  PLATO.  The  most  basic  incompatibilities  are  those  of  data 
representation  introduced  either  by  the  hardware/  for  instance  a 
wor  f  si2e  of  64  instead  of  6  0  bits  and  two's  instead  of  one's 
complement  arithmetic/  or  by  the  software/  such  as  an  8  bit  extended 
ASCII  character  set  instead  of  an  extended  6  bit  display  code- 


Incompatibilities  in  the  support  of  common  and  storage 
introduced  by  a  chanae  from  ecs  to  disk  based  backing  storage/  or  by 
the  use  of  a  paged  virtual  memory  also  fall  into  this  first 
category.  However/  these  areas  are  hiohly  system  dependent  and  as 
such  are  not  within  the  realm  of  this  paper. 

Other  incompatibilities  have  been  introduced  in  order  to  obtain 
a  reater  degree  of  freedom  in  the  choice  of  implementation 
approach.  These  include  restrictions  on  changing  the  increment  and 
bounds  of  d  -doto-  loop/  irnd  limitations  on  the  use  of  -goto-  and 
-branch-  with  respect  to  judging  blocks. 

further  problems  with  compatibility  are  sure  to  arise  in  the 
future  as  the  TUTOR  lanquage  and  PLATO  system  evolve.  This 
evolution    can   only   be   encouraged   because   the   TUTOR   lanyuage 
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currently  has  many  shortcomings.  In  light  of  this/  it  can  be  asked 
what  value  there  is  in  tryino  to  support  TUTOR  on  a  small  machine  if 
it  is  not  possible  to  maintain  compatibility  with  the  only  major 
implementation  of  the  lanquage.  The  most  important  justification  is 
probrbly  that  a  small  implementation  allows  a  oegree  of 
experimentation  that  is  not  possible  on  the  large  central  PLATO 
system  which  is  bound  by  its  larqe  user  community. 

7.3.  EPILOGUE 


Though  ex^ct  compatibility  between  the  PLATO  implementation  of 
TUTOR  and  one  on  a  small  to  medium  scale  machine  may  well  be 
impossible/  all  of  the  important  features  of  the  lanquage  can  be 
supported  in  a  manner  flexible  enough  to  be  quite  useful.  It  is 
hoped  that  the  demonstration  of  this  will  open  the  way  for  numerous 
experiments  in  the  support  of  TUTOR  like  abilities  on  smaller 
systems/  as  well  as  encouraqe  the  application  of  hiqhly  interactive 
oraphic  computing  in  new  areas. 
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APPENDIX  A  -  SUMMARY  OF  THE  EXECUTION  OF  TUTOR 

The  fotlowinq  material  is  reproduced  with  permission  from  the 
AIDS  information  system  on  (and  about)  PL^TO.  This  is  not  a 
complete  summary  in  that  some  states  are  not  clearly  described  and 
the  interaction  of  the  various  states  with  subroutines  is  larqely 
omi  1 1 ed. 

PSO  Author  Group CERL 

Univ  of  Illinois,  Urbana 
©  Copyright,  1973,  197  1,  1975,  19  76  Board  of  Trustees 
of  the  University  of  Illinois 

regular  state 
judge  state 

Only  regular  commands  er^:   executed  in  regular  state, 
TUTOR  skips  all  other  commands.   Regular  state  ends 
when  a  judging  command  i-s  encountered  or  when  the  end 
of  the  main  unit  is  reached.   In  judge  state  TUTOR 
execut  es  on  1  y  j  udg  i  ng  commands ,  sk  i  pp  i  ng  all  ot  her 
commands.   Judge  state  ends  when  a  response  is  matched 
or  when  the  judging  region  ends  Cat  an  -endarrow-, 
another  -arrow-,  or  the  ^.nd   of  the  main  unit)  . 

search  state 
condense  t  i  me 

During  search  state,  only  -join-  is  executed.   fill 
other  commands  are  skipped.   Search  state  ends  when 
en  -endarrow-,  another  -arrow-,  or  the  end  of  the  main 
unit  is  reached.   Encountering  an  -endarrow-  or  another 
-arrow-  in  search  state  causes  TUTOR  to  switch  to 
regular  state.   TUTOR  then  continues  processing  in 
regular  state;  executing  regular  commands.  ! The  non- 
executable TUTOR  commands  set  pointers,  make  lists, 
and  other  functions  when  a  lesson  is  condensed.   The 
non- executable  are  skipped  when  TUTOR  is  executing. 
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*'l   When  a  lesion  is  condensed,  the  non-executable  TUTOR 

commands  set  pointers,  make  lists,  and  other  functions. 
When  TUTOR  is  executing  in  regular  state,  judge  state, 
or   search  state,  all  non- executable  commands  are  skipped. 

TUTOR  starts  execution  of  a  lesson  in  regular  state. 
The  commands  before  the  first  -unit-  command  (the  i .. e.u.) 
are  executed.   TUTOR  enters  the  first  main  unit  in 
regular  state;  TUTOR  proceeds  to  #2. 


#2   Regular  commands  are  executed  in  a  sequential  manner. 

If  an  -arrow-  was  one  of  the  regular  commands  executed, 
TUTOR  remembers  the  location  of  that  command  in  the 
unit  (sets  the  -arrow-  marker) . 

If  the  -arrow-  marker  was  set,  execution  in  regular 
state  ceases  when  a  judging  command  is  reached  and 
TUTOR  proceeds  to  #4 

If  no  -arrow-  command  was  executed  (no  -arrow-  marker  . 
was  set),  execution  in  regular  state  ceases  when  the  end 
of  the  main  unit  is  reached  and  TUTOR  proceeds  to  #3. 


#3  The  main  unit  named  in  the  tag  of  the  -next-  is  bran- 
ched to  wh^n  the  NEXT  key  is  pressed.  If  there  is  no 
-next-  command,  TUTOR  branches  to  the  unit  which  phy- 
sically follows  the  current  unit  when  the  NEXT  key  is 
pressed.  The  student  may  also  exit  this  "completed" 
main  unit  by  pressing  an  active  function  key,  e.g.  HELP; 
or  execut  i  ng  a  -  j  urnp-  or  -  j  urnpout  - . 

The  new  main  unit  is  started;  TUTOR  proceeds  to  *2. 
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#4  TUTOR  waits  for  a  student  response.   Judge  state  begint 
when  the  student  presses -the  NEXT  kev,  an  act  ive  -  jkey- , 
after  the  first  character  with  a  -long   1-  in  effect, 
or  when  the  length  limit  is  reached  and  a  -force   long- 
is  in  effect. 

When  judge  state  begins,  TUTOR  starts  at  the  command 
after  the  -arrow-  and  executes  judging  commands  in  a 
sequential  ordeir   until  a  match  is  found  or  the  region 
of  judging  ends.   The  region  of  judging  ends  when  an 
-endarrow-,  another  -arrow-;  or  the  ^trid   of  the  main 
unit  is  reached. 

If  a  -specs-  was  one  of  the  judging  commands  executed, 
TUTOR  remembers  the  location  of  that  command  in  the 
unit  (a -specs- marker  is  set).   If  more  than  one  -specs - 
was  executed,  the  last  -specs-  executed  serves  as  the 
"specs  marker".   TUTOR  proceeds  to  *5.- 


*5   If  a  judging  command  was  matched,  TUTOR  executes  reg- 
ular commands  following  that  matched  judging  command 
until  another  judging  command,  an  -endarrow-,  another 
-arrow-,  or  the  end  of  the  main  unit  is  reached.   The 
automatic  response  mark  up  is  displayed  and  the  judgment 
is  set  (either  "ok"  or  "no1')  .   TUTOR  proceeds  to  *6. 

If  a  judging  command  was  not  matched,  TUTOR  judges 
"no"  and  the  automatic  response  mark  up  is  displayed. 
TUTOR  proceeds  to  *6. 
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*6   If  a  -speco-  marker  was  set  for  the  current  -arrow-, 

TUTOR  begins  at  the  command  following  the  last  - specs - 
executed  in  regular  state.   fill  regular  commands  are 
executed  until  a  judging  command,  - endarr ow - ,  another 
-arrow-,  or   the  end  of  the  unit  is  reached. 

If  the  -arrow-  was  judged  "no",  the  student  must  erase 
all  or  part  of  the  response  by  pressing  NEXT,  EDIT,. 
shift-EOIT,  ERfiSE,  shift-ERRSE,  or  an   active  -jkey-. 
The  auto  erasing  of  the  last  comment,  the  judgment,  and 
the  automatic  response  mark  up  also  occurs  (and  the 
erasing  by  an  active  -eraseu-)  when  the  student  erases 
part  or  all  of  the  response.   TUTOR  return  to  #4. 

If  the  -arrow-  was  judged  HokH,  TUTOR  proceeds  to  #7 
in  search  state. 


*7   flfter  the  response  was  judged  "ok",  TUTOR  returns  to 
the  command  after  the  -arrow-  to  search  (search  state) 
for  an  -endarrow-,  another  -arrow-,  or  the  &id   of  the 
main  unit  (-join-  is  executed  in  search  state,  as  well 
as  in  regular  state  and  judge  state) . 

If  an  -endarrow-  is  reached,  TUTOR  changes  from  search 
state  to  regular  state  and  executes  regular  commands 
just  as  i f  a  new  main  unit  was  entered  (except  there 
is  no  clearing  of  the  main  unit  pointers  or  automatic 
panel  erasure) .   TUTOR  proceeds  to  #2. 

If  another  -arrow-  is  reached,  TUTOR  changes  from  search 
state  to  regular  state.   The  new  -arrow-  marker  is  set 
and  TUTOR  continues  to  execute  regular  commands  until 
a  judging  command  is  reached.   TUTOR  proceeds  to  *4. 

If  the  end  of  the  main  unit  was  reached  in  search  state, 
TUTOR  proceeds  to  *3. 
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APPENDIX  B  -  SPECIFICATIONS  FOR  THE  INTEPRETER 


B.1 


PROGRAM  STATUS 


The  elements  of  the  program  status  defined  here  are  those 
necessary  for  the  intermediate  code  interpreter  approach  to  TUTOR 
execution;  they  are  in  addition  to  those  required  by  the  various 
TUT  ~>R  commands/  which  are  adequately  discribed  in  other  references 
[11  ,19D. 


B.1  .1 


4  JUDGING  STATUS  BITS/  NOT  SAVED  IN  LINKAGE 


0000  -  Regular  state. 

0001  -  Post  -iirrow-  regular  state. 

100C  -  Judging  state  (searching  for  judgment). 

0100  -  Post  judging  regular  state/  "ok"  judgment. 

0010  -  Post  judoing  regular  state/  "no"  judgment. 

1100  -  Searching  for  -specs-  with  "ok"  judgment. 

1010  -  Searching  for  -specs-  with  "no"  judgment. 

0101  -  Post  -specs-  regular  state/  "ok"  judgment. 

0011  -  Post  -specs-  regular  state/  "no"  judgment. 

1101  -  Searching  for  -er.darrow-  with  "ok"  judgment 

1011  -  Searching  for  -endarrow-  with  "no"  judgment 


B.1  .2 


4  UNIT  TYPE  «ITS/  SAVED  IN  LINKAGE 


1xxx  -  Parameters  on  stuck  to  be  resolved. 

xlxx  -  Unit  entered  by  -do-  or  -join-. 

xxxl  -  Reserved  for  future  experiments  with  -helpop-. 

B.1  .3-   OTHER  PARTS  SAVFD  IN  PROCEDURE  LINKAGE 

PC  or  INTERPRETER  PROGRAM  COUNTER;  this  is  a  16  bit 

pointer  into  a  vector  of  8  hit  bytes  (the  program  space) 

BASE  UNIT  POINTER;  this  is  a  16  bit  pointer  into  the 
program  space  for  interrupt  return  applications. 


LINK  or  STACK  LINKAGE  POINTER;  a  16  bit  pointer 

into  a  vector  of  64  bit  elements  (the  stack) 
This  pointer  is  used  to  allow  recursive  and 
nested  subroutine  calls. 
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FJ.1.4.   OTHER  PARTS  NOT  INVOLVED  IN  LINKAGE 

MAIN  UNIT  POINTER;  a  16  bit  pointer  into  the  program 

spsce  copied  from  the  program  counter  on  main  unit  entry 

SP  or  STACK  POINTER;  a  16  bit  pointer  into  the 

strck  used  by  all  computational  instructions  and 
all  parameter  passing  mechanisms.   The  push  operation 
increments  the  SP  before  stcrinq  a  value/  and  the  pop 
operation  aecrements  after  recovering  a  value. 


B.1.5.   SEGMENT  DEFINITION  TABLE 

This  table  has  32  entries/  containino: 
Segment  base  address/  16  bits. 

Seqment  entry  size/  6  bits  specifying  number  of  bits  per  entry 
Si?n  extender/  1  bit  specifyinu  that  entries  are  signed. 
Floater/  1  bit  specifying  entries  in  floatinc  point  format. 

The  first  four  entries  in  the  segment  table  are  predefined  to: 

0)  System  wide  status  variables  (a  special  common  block). 

1)  User  dependant  status  variables. 

2 )  User  variables. 

3)  Common  ^  n  d  storaoe  share  this. 

4)  Router  variables  (if  implemented). 

b  .2  .   DATA  FORMATS 


P. 2.1 


SIMPLE  DATA  TYhF.S 


Integers  are  stored  as  64  bit  two's  complement  values.  Integer 
arithmetic  operations  use  only  the  least  significant  32  bits  ana 
sign  extend  their  results  to  6A  lits/  comparison  operations  work 
over  the  entire  64  bits  as  do  bit  manipulation  operators. 


Floatin    point   data   is   stored 
format  supported  by  the  host  machine. 


in  the  64  bit  floating  point 
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Alphanumeric  data  is  stored  in  8  bits  per  character/  with  the 
least  significant  seven  bits  interpreted  as  ASCII  when  the  most 
significant  bit  is  zero/  and  as  additional  PLATO  characters  when  the 
most  significant  bit  is  one.  When  a  I ph anumer i c  data  is  packed  into 
integers*  the  last  or  rinhtmost  character  occupies  the  least 
sianificant  bit  position. 

boolean   data/   which  is  produced  as  the  result  of  comparisons/ 

and  is  interpreted  by  the  branch  on  false  instruction/  is  compatable 

with   PLATO   and  the  table  lookup  branch:  true  is  -1  or  negative  and 
false  is  zero  or  positive. 

P. 2. 2.   MEMORY  ADDRESS  ^RMAT 


Memory  addresses    may  be   provided   either   as 

significant  three   bytes   of  a   6  4   bit   stack   entry 

consecutive  bytes   from   the  instruction  stream  in  some 

format  is  as  follows: 


the  least 
or  as  three 
cases.   The 


XXSSSSSF  00000000  00000000 

where   X   is   ignored/  S  indicates  which  segment/  and  0  specifies  an 

offset   from   the   base  of  that  segment  in  terms  of  the  word  size  of 

that  seament.   r  indicates  the  type  of  the  data  that  the  location  is 
expected  to  holci  (0=integer/  1  =  real). 


P.?.? 


LOOF  CONTROL  BLOCK  FORMAT 


STACK  LSP3  =  increment  value. 

STACK  CSP-13  =  limit  value  for  index. 

STACK  CSP-rD  =  initial  value  for  index 

STACK  CSP-3D  =  memory  address  of  index 


P. 2  .4 


LINKAGE  WORD  FORMAT 


The  current  linkane  word  occupies  one  st^ck  entry  and  is 
pointed  to  ty  the  LINK  register  when  executing  within  a  subroutine. 
There  are  fields  in  this  word  for  all  the  data  of  P. 1.2  and  b.1.3. 
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R.2.5.   PARAMETER  TYPE  V.ORt)     FORMAT 

The  parameter  type  word  occupies  one  stack  position  and 
consists  of:  ?P  entries  givinu  information  about  up  to  28 
parameters/  and  an  8  bit  count  of  the  number  of  parameters 
immediatly  below  this  word  on  the  stack,  the  least  significant 
entry  corresponds  to  the  topmost  element  on  the  stack  below/  the 
most  signifigant  fc  bits  are  the  count.  The  two  bit  fields  for  each 
parameter  have  the  following  meaning: 

Ox  -  parameter  missinq  (no  corresponding  stack  entry). 

10  -  the  corrpspondinr  word  is  an  integer. 

11  -  the  corresponding  word  is  floating  point. 

1*2.6.   MASK  PYTES  FOR  STATUS  TESTING 

A  numter   of  interpreter  instructions  test  the  bit  patterns  of 

b.1.1  and   B.1.2   with   the  aid  of  a  mask.   *ll  such  masks  have  the 

common  format:   11112222*   where   the   bits   marked   1  are  those  of 

B.1.1/  and  those  marked  2  are  R.1.2. 


B.2.7 


SPECIAL  DATA  IN  THE  PROGRAM  SPACF 


When  constants  requirinq  more  than  P  bits  are  stored  in  the 
pronram  space/  they  ire  stored  most  significant  byte  first.  This 
holds  for  16  bit  proaram  space  adaress  constants/  24  bit  data 
address  constants/  and  16/  32/  arid  64  bit  integer  constants. 


P.  3 


INTERPRETER  INSTRUCTIONS 


The  instructions  listed  Fere  provide  the  needed  support  for 
TUTOR/  and  thf  required  computational  ability.  The  actual  TUTOR 
action  routines  are  not  listed  here. 

Each  instruction  is  identified  by  its  first  f  bits/  the 
instruction  number.  The  action  routine  for  each  instruction  may 
consume  additional  bytes  containino  constant  data  or  addresses/  but 
almost  all  instructions  are  fixed  format;  ir  they  may  consume  an 
extra  byte  of  information/  they  will  almost  always  consume  it.  Most 
instructions  also  have  a  fixed  effect  on  the  stack/  always  reading 
and  popping  or  creatine  and  pushing  a  fixed  numher  of  entries. 


Instructions  that  need  variable  numbers  of  parameters  are 
implemented  with  a  well  defined  fixed  (art  containing  the 
ipecifi cat  ions  of  the  variable  parts. 
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pos  t  in 

0 1  bloc 
tinn/  t 
en  the 

stack; 
nst  ruct 
d  point 

the  ad 

prechec 
o I  bloc 
I  va I ue 
i  t  h  i  n  b 
en  and 


to  that  address. 

on  false  and  pop  stack. 

ress>:  table  lookup  tranch. 

the  stack  top  is  ore  t  e  r 

t  is  used  as  a  value.  If 

1  is  used.   A  branch  is 

ified  by  the  woro  addressed 

the  oiven  address/  and  the 

stack. 

d  e  x  check  and  branch. 

k  on  the  stack. 

he  index  valup  is 

stack  control  tlock 

otherwise  the  branch 
ion  works  tor  both 

on  the  basis  of  the 
dress  in  the  stack 

k  loop  encJ  branch. 
k  on  the  stack. 

in  the  i  nde  x /  then 
ounds  .   If  not/ 
the  stack  control 


<16  bit  address>:  branch  on  status  set. 
<16  bit  address>:  branch  on  status  clear. 

<16  bit  address>:  Call, 
indicates  parameters  on  the  stack/ 

obtained  from  the  parameter  type  word, 
status  save  word  is  stored  in  st ^ck 
count/  and  the  L I n K  woru  is 
hat  location.   The  least  significant 
e  mask  replace  tne  linkage  status  bits/ 
is  transfered  to  the  address. 
:  return  conditional  on  any  of  the 
inkage  status  bits  matchinc  those 
ask.   The  return  consists  of  fetching 
status  save  word  from  the  location 
y  tho  link. 

<16  bit  address>:  branch  with  parameters, 
ored  with  the  status  byte  end  control 
d  to  the  add  r ess  . 

<16  bit  address  > :  -do-  -join-. 

exceot  -do-  -join-  Lit  is  set  automaticlly 
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#14 


#15 
016 


<8  bit  mask>  <8  hit  mask>  <16  bit  address>:  special 

status  checking  branch.   If  any  status  bit  matches 

a  bit  set  in  the  first  mask  and  no  bits  match  the  second 

mask*  then  branch. 

<8  bit  mask>:  set  bits  in  status. 

<8  bit  mask>:  c I r  a  r  bits  in  status. 


3.2 


DATA  FETO  AND  STORE 


#20 

#21 


#22 

#24 
*25 
#26 
#27 
#28 
#29 
#32 


#33 

#49 

#50 


<24 

<16 

Form 

S  i  an 

<8  b 

prov 

<64 

<32 

<16 

<8  b 

rep 
<24 

sto 
Repl 
the 
<24 

pop 

rep 
<8  b 


bits 

bits 

at  X 

i  f  iq 

its 

idin 

bits 

bits 

bits 

i  ts 

lace 

bit 

re  d 

ace 

or  iq 

bit 

wor 
I  i  ca 
it  s 


of 

of 
XSSS 
ont 
of  d 
n  se 

of 

of 

of 
uf  d 

add 
addr 
ata 
t  he 
i  ona 
addr 
d  f  r 
tew 
i  g  n  e 


data 

data 

SSF 

byte 

ata> 

qmen 

data 

data 

data 

ata> 

ress 

ess> 

thro 

addr 

I  co 

ess> 

om  s 

ord 

d  va 


>: 

>  : 

00 
O 

t 
>: 

>  : 

>  : 


ug 
e  s 

py 

ta 

on 
lu 


pus 

pus 

0000 

f  th 

conv 

info 

pus 

pus 

pus 

push 

n  st 

push 

h  ad 

s  w  i 

of 
st  or 
ck. 

sta 
e>: 


h  immediate  address  onto  stack. 

h  immediate  short  address  onto  stack 

00  (see  B.2.2)  where  the  most 

e  offset  is  assumed  to  be  zero. 

ert  integer  to  aadress  by 

rmation. 

h  immediate  64  bits  onto  stack. 

h  immediate  32  bits  siqn  extended. 

h  immediate  16  bits  siun  extended. 

immediate  ft  bits  sion  extended, 
ack  with  the  data  it  points  to. 

data  from  immediate  address, 
dress  below  it  on  stack, 
th  the  data*  and  pop 
the  data  from  the  stack. 
e  data  in  immediate  address. 

c  k  t op  . 

modify  S F  by  addinj  value. 


PINAFY  INTEGER  OPERATORS 


#55 
#56 
#57 
#58 
#59 
#60 
#61 
#6? 
#63 
064 
#65 


replace  the  top  two  stack  elements  by  their  sum 

subtract  stack  top  from  the  value  under  it. 

multiply. 

divide  the  stack  top  into  the  value  under  it. 

produce  the  remainder  as  in  division. 

(SP-1)=(SP)  replaces  the  elements  compared. 

(SP-1 >\= (SP) 

(SP-1 )> (SP) 

(SP-1)>=(SP) 

(SP-1 )<(SP) 

(SP-1 )<=(SP) 
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b.3.4 


BINARY  FLOATING  POINT  OPFRATORS 


#66 
#69 

*70 
<>72 
"73 
+  7U 
*75 
'-•76 
£77 


repl.ce  the  top  two  stack  elements  by  their  sum 
subtract  stack  top  from  the  value  under  it. 
mult  i p I y . 

divide  the  stack  top  into  the  value  under  it. 
(SF-1)=(SP)  boolean  comparison  for  equality. 

\- 

> 

>  = 

< 

<  = 


E-.3.5.       POOLF/iN     AND    BIT     OPERATORS 


#P0:  boolean  and 

#L1 :  boo  I ean  or . 

fib?:  boolean  exclusive  or. 

#*3:  bitwise  and/  mask/  or 

H  h  4  :  bitwise  or/  merge/  or 

#85:  bitwise  exclusive  or/ 

#*6:  logical  left  shift  (SP-1) 

#87:  logical  right  shift. 

»:&:  arithmetic  riaht  shift. 

#F  9:  circular  left  shift. 


of  the  top  two  stack  elements. 


intersection  operator. 

union. 

or  difference. 

by  (SP)/  pop  count 


B.3.1* 


COMPLEMENTATION  OF  STACK  TOP 


H  9  0 : 
#91: 

t9?'. 
*9lr 


INTFGFR 
FLOATIN 
BOOLFAN 
BITWISE 


N  F  G  A  T  E 
POINT 
NOT  . 
NOT  OR 


NEGATE  . 


ONES  COMPLEMENT 


P  .  3  .  7 


ODDS  ANT  FNDS 


#  *■>  5 :  convert  inteqer  to  floating  point  on  stack  top. 

t;9  6:     convert  floatino  point  to  integer  by  truncation. 

ff^7:  integer  part  floatino  point  number  in  floating  point. 

H9c  :     fractional  part  of  floatino  point  number. 

#99:  convert  floatino  point  to  inteoer  by  rounding. 

-100:  replr.ee  stack  top  with  integer  count  of  1  bits  in  it. 

#105:  convert  coarse  to  fine  grid  (replace  top  by  two  words) 
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B.3.E.   FUNCTION  LIBRARY 


*12F: 
0129: 
#130: 
*131  : 
0132: 
#133: 
MAO: 
U  141: 
(M42: 
#143: 
#146  : 
#147: 


rep  I 
cosi 
t  ann 
arc 
arc 
arc 
lo.  1 
logo 
ant  i 
ant  i 
expo 
squc 


*ce  stack  top  with  sine  of  stack  top  (floating  point) 

ne  (  radi  ans). 

ent  . 

sine. 

cosine. 

tanqent . 

0. 

I  o  o  1  0  . 
I  o  g  e  . 
nent  i  at  e  . 
re  root . 


B.3 


SPECIAL  TUTOR  COMMANDS 


#251:  begin  new  main  units  reset  all  but  parameter 
bit  in  program  status/  copy  any  parameters  down 
the  stacks  erase  terminal  screen  and  reset  mode. 
If  an  '  i  m  a  i  n  '  unit  exists^  call  it  with  no  parameters. 

ft 253:  end  main  units  wait  for  any  armed  keypress 
or  NEXT.   If  NEXT  is  pressed  and  there 
is  a  desionated  next  unit  to  branch  to  do  so^ 
otherwises  fall  throuah  to  the  next  unit  when 
NEXT  is  pressed. 

#255:  prefix  for  other  TUTOR  commands 
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APPENDIX  C  -  INTERMEDIATE  CODE  COMPILATION  EXAMPLES 

C.1.   EXPRESSIONS 

TUTOR  CODE:   cdc     n1  :  =n1 +n (n2 : =n2  + 1 ) 


INTERMEDIATE 


1 

#20 

2-4 

<n1> 

5 

#49 

6 

#28 

7 

#20 

8-10 

<n2> 

1  1 

#49 

12 

#28 

13 

#27 

U 

=  1 

15 

#55 

16 

#32 

17 

#22 

18 

<n> 

19 

#28 

?0 

#55 

?1 

#32 

22 

#48 

CODE/  COMMENTARY: 

rush  cddress  onto  stack 

24  hit  address  of  n1 
replicate  address 
fetch  n1 
push  address  onto  stack 

24  hit  address  of  n  2 
replicate  address 
fetch  r>? 
push  constant  onto  stack 

8  hit  const  ant  1 
i  nt  eqe  r  add  n2  +  1 
store  n2 :  =  n2  +  1 
convert  the  sum  into  an  address 

make  it  n(n2:=n2+1) 
fetch  n(n2:=n2+1 ) 
inteqer  add  n1 +n (n2 : =n2+1 ) 
store  n1 : =n1 +n (n2  :  =n2  +  1 ) 
pop  the  stack  to  its  oriqional  state 


C.2.  SIMPLE  COMMANDS 

TUTOR  COD F:  <t        1010 

INTERMEDIATE  CODE/-  COMMENTARY: 
1        #26        push  constant  onto  stack 
2-3     =1010        16  tit  constant  1010 

4  #105       convert  coarse  (1010)  to  fine  (72/352) 

5  #255       TUTOR  command  follows 

6  <at>         the  code  for  -at-  (pops  2  parameters) 


C.3.   CONDITIONAL  COMMANDS 
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TUTOR  CODE:  coles 


n1 *n2 : =n3/0*-n3 


INTFRMEDI ATE 

1 

#20 

2-4 

<n2> 

5 

*29 

6-8 

<n1> 

9 

#3 

10 

=  1 

11-13 

=  36 

14 

#29 

15-17 

<n3> 

18 

#1 

19-20 

=  40 

21 

#27 

22 

=0 

23 

#1 

24-25 

=  40 

26 

#29 

27-29 

<n3> 

30 

#90 

31 

#1 

32-33 

=  40 

34-35 

=  14 

36-37 

=  21 

38-39 

=  26 

40 

#32 

41 

#48 

CODE 


AND  CO 
push  z 

th 
push  d 

ad 
table 

th 

th 
push  d 

ad 
br anc  h 

ad 
push  i 

z  e 
branc  h 

ad 
push  i 

ad 
i  nt  epe 
branc  h 

ad 
t  3ble 
table 
t  sble 
store 
pop  r  * 


WMEN 
dare 
e  ad 
at  a 
dres 
look 
e  nricj 
e  0 
ata 
dres 

to 
dres 
mmed 
ro 

to 
dres 
rom 
dres 
r  ne 

to 
dres 
addr 
addr 
addr 
r  esu 
suit 


TARY 
ss  i 
dres 
from 
s  n1 
up  b 
x  imu 
ent  r 
from 
s  n3 
end 
s  of 
i  at  e 


n  which  to  store  result 
s  of  n? 
immediate  address 

ranch 

m  i  nde x  i  s  1 

y  o  *  the  jump  table  is  at  36 
immediate  address 

of  conditional 
end 
constant 


end  of  cond  i  t  iona  I 
s  of  end 

immediate  address 
s  n3 

qate  -ni 

end  of  conditional 
s  of  end 

ess  for  neqative  index 
ess  for  7ero  index 
ess  for  positive  index 
It  in  adaress  below  it 
value  off  of  stack 


<n2) 


C.4.   LOOPINl  COMMANDS 

TUT^R  CODE:  do       uni t 1 /n 1 : =1 , 1 00, 5 
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INT.'  RMEDI  ATfc  CODE,  COMMENTARY: 


1 

#20 

2-4 

<n1> 

5 

»27 

6 

=  1 

7 

027 

8 

=  100 

9 

»27 

10 

=  5 

11 

tit 

12-13  =21 

14  *13 

15  =0 
16-17  =<unit1> 

n    <»5 

19-20  =14 


Dush  index  address  onto  stock 

address  n1 
push  initial  value  onto  stack 

vnlue  1 
push  final  value  onto  stack 

v< lue  100 
push  increment  value  onto  stack 

v.  lue  5 
loop  control  block  ^rerheck  and  setup 

address  beyond  end  of  loop 
-do-  -join- 
no  parameters 

address  of  entry  point 
loop  rontrol  block  post  index  and  branch 

address  of  top  of  loop 


(C.4.   LOOPING  COMMANDS  continued) 

TUTOR    CODE:     rioto  1  lab^ril  :  *1-0>'2#-1 

branch   n(n1)/2lab/X/1lab 

n(n1) :=-1 
11  ah 
?lab 
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INTFRMEDIATE  CODE/  COMMENTARY: 

I  #20  push. address 

2-4  <n1>  address  of  n1 

5  #27  push  immediate  co 

6  =10  initidli  ndex 

7  #27  push  immediate  co 

8  =  2  f  ina  I  i  ndex  v 

9  tt?7  push  immediate  co 

10  -  - 1  ir.  crementvat 

II  »6  loop  control  bloc 
12-13  =49  address  beyon 
14  #29  push  from  immeaia 
15-17  <n1>  address  of  n1 

18  i>22  convert  integer  t 

19  <n>  specify  stude 

20  #28  fetch  n(n1) 

22  #255  TUTOR  command  fol 

23  £<branch>     conditional  bra 

24  =-4  pop  4  levels  be 

25  =1  maximum  index  v 
26-27  =4*5  address  for  ind 
28-2^  =0  no  f  ranch  on  in 
30-31  =44  address  for  1  o 
32  #29  push  d eta  from  im 
33-35  <n1>  rddress  of  n1 

36  #22  convert  n1  to  the 

37  <n>  space  attribute 

38  #27  push  immediate  8 

39  =-1  const  ant 

40  #32  store  n(n1):=-1 

41  #48  pup  h?ck  to  the  I 

42  #50  prepare  for  label 

43  =-4  Lytemporaril 

44  #50  1lab  is  here/  rec 

45  =4  by  restoring. 

46  #5  postcheck  loop  co 
47-48  =14  address  of  to 


/  loop  index 
nstant 
value 
nstant 
a  lue 
nstant 
ue 

k  precheck  and  initialize 
d  end  of  loop 
te  memory  adaress 

o  add  ress  of  n<n1) 
n t  variables  (n) 

lows 

nch  with  Iool  exit  ability 

fore  branch  i  ng 

a lue  is  1 

px  ne  jat  i  ve  /  2  I  a  b 

de  x  zero 

r  positive/  1  I ab 

mediate  address 

.idd  ress  n(n1) 
for  stack  top 
>its  of  data 


oop  control  block 

i  nsi  cie  loop 
y  poppino  loop  control  block 
over  loop  control  block 
stack  pointer 
ntrol  block  and  loop  back 
p  of  loop 
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/>PPFNDIX     D     -     COMPILATION    OF     UNITS     AND     JUDGING    SIQUENCES 


of 
*  or 


r  t  of  this  appendix  is  an    example  of  the  structure 

TUTOR.   This  is  useful  as  a  basis 


The   first  pai 

<n  -arrow-  -endarrow-  block  in 
understanding  the  remainder  of  this  appendix  which  is  a  listing 


■or  unutrsidnoinu  me  remainaer  ot  mis  appenaix  wnicn  is  a  listing 
of  the  'templates*  used  in  compiling  the  special  judging  statements 
of  TUTOR  into  the  instruction  set  of  appendix  B .  Throughout  this 
appendix*  the  aspects  of  TUTuR  judqing  relating  to  its  control 
structure  are  emphasized  at  the  expense  of  the  data  manipulation  and 
input/output  sice  effects  of  the  commands. 

D.1.   RFDUCTION  OF  A  JUDGING  BLOCK  TO  A  FLOWCHART 


TUTOR  CODF.  : 


arrow 
write 

answer 
wr  i  t  p 

wrong 

write 


1010 

b 
c 

d 
e 


spec  s 

wr  i  t  p  f 

answer  g 

write  h 


w  r  o  n  :■ 
write 

specs 
wr  i  t  ( 


answer   I 

write    m 

w  r  on  .     n 
writ'    o 

end  r  row 


FLOWCHAI- 

T  : 

arrow 
write 

■ 

11 
a 

10 

j  udge  ok 
write  c 


j  udge  no 
write  e 


j  u d o e  ok 
write  h 

j  uaqe  no 
write  j 

write  t 


j  udae  ok 
write  m 


j  udge  no 
write  o 


>■  j  udge  no 


write  k 
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0.2 


A  STRUCTURED  REDUCTION  OF  THE  SAME  CODE 


arrow (1010); 

writeC'a"); 

REPEAT 

input  I 

BEGIN  UNTIL  specsl  OR  specs?; 
IF      it-is("h") 

THEN  <ok;write("c")} 
ELSEIF  it-isC'd") 

THEN  <no;write("eM)} 
ELSE  IF  it -is ("a") 

THEN  Cok;write("hM);specs1> 
ELSEIF  it-is ("i") 

THEN  {no;urite("j");specs1} 
ELSEIF  i  t - i  s ( " I " ) 

THEN  {ok;write("m");£pecs2} 
ELSEIF  it-is<Mn") 

THEN  Cn6;write("oM);spccs2> 

WHEN 

specsl:  writeC'f"); 

specs?:  writeC'k"); 
END 

UNTIL  judqedok; 


Note  that  the  UNTIL  clause  is  d  declaration  ot  the  exit  blocks 
that  actually  occur  in  the  WHEN  clause.  This  notation  is  an 
adaptation  of  that  employed  by  Knuth  L1?D. 
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P. 3 


fARTIM  COMPILER  SPECIFICATIONS  FOR  TUTOR  JUDGING 


"Data  definition  for  compilation  of  TUT<  R  judging" 

T  Y  F  T   r  o  m  m  a  n  a  =  (abort/addlst/addl/allow/  ...  /wronv/zero); 

states  =  (s_renulor/S_postrirrow/s_post  juduino/s_pnstspecs 

/s_judqina/S_specs#s_endarrow); 
link  -  "defined  bv  procedures  <de f i ne / unde f i ne/ t o> " ; 

"Imjortnt  powersets  of  commands" 

CONST  always_ends_judginq  =  fok/no/in^tch/  ...  } ; 

sometires_ends_judqinn  =  tans  we r/wronu/Stcre/  ...  >; 

never_pnds_juo«]in(|  =  <storea/put/bump/  ...  j; 

judoin':  =  always_enris_juauinq  +  sometimes_ends_judging 

+  never_ends_judqinj; 

"Special  state  powersets" 

g_regular  -  <s_reoular/s_post  Rrrow/S_.postjudcing*s_postspecs}; 

a  _  s  e  a  r  c  1 1   =  ■Cs_jua^inj/S_specs/s_endarrow); 


'Constants  for 
b .sea r c  h 
b  _ok  _no 
b_specs 
b  do j  o  i  n 
b  ok  nc 


code  qene  ration/ 

-  ionoooooi2; 

=  ( 1 1000UCb2; 

=  r^ooioonot^; 

^  f'0{)00100b2; 
_srecs  =  nnooocb?; 

b_search_ok_no_specs  =  111100  0  0 t  2  ; 
b_search~specs~=  1 '  010000b?; 


status  test  masks  Isee  !.1J" 


Constants  for 

o  _b  r  an  c  h 
o.branch 
o  _b  r  a  n  c  h 
o  _  r  et  u  r  n 

o  branch 


rode  generation*  instruction  names  [see  P..3J 

•  i; 

i  f  _  s  e  t  =  7 ; 
if_reset  =  hi 
i  t  _  s  e  t  =  11; 
if  set  reset 


=  13; 


o_set_status  =  15; 
t  reset  status  =  16; 
o  re  ad  line  =  "command 


to  act  input  and  initiate  judcinq"; 
o_markup  -  "command  to  output  rrirkup  and  enter  post_specs"; 
o_endarrov»  -  "command  to  select  ro;ular  or  post_arrow  states' 


'Pr.inch  tables  used  to  nener.^te  judging  code 


V  A  R    Irenular 
/ I _s  pec  s 
/ I  markup 
/ I _  e  n  d  a  r  row 
/ I _  i  nuut 
/ I _j  ud'  i  nq 
/  l_endur.it 
:  I  i  n  k  ; 


"foreword  branch  in  s_reoular  state" 

"backward  branch  in  Cs_postjudjino/S_specs>  state" 

"foreword  branch  iri  {s_postjudeinq/S_specs>  state" 

"foreword  branch  in  -Cs_postspecs/S_endarrow>  state" 

"branch  in  s_postarrow  state" 

"foreward  branch  in  s_judging  state" 

"foreword  in  {s_jud"inn>+(n_reaular--Cs_reqular})M 
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"Main  compilation  control  variables" 

state:  SET  OF  states; 

"This  variable  identifies  the  set  of  states  in  which" 
"the  code  being  compiled  is  expected  to  execute.  " 

t hi s_command :  command; 

"This  variable  identifies  by  name  the  command  for" 
"which  code  is  currently  beinq  generated. " 

no_ar row_in_un i t :  boolean; 

"This  flag  is  used  to  select  between  the  two  possible" 
"types  of  -endarrows-  (-ea-  for  joined  unit  or  normal)" 

i nput _r equest ed :  boolean; 

"This  flag  is  used  to  guarantee  that  the  'first  judging 
"command  after  the  arrow'  is  well  defined" 

"Procedures  for  code  generation" 
PROCEDURE   codeout (b:byte); 

"places  the  value  of  <b>  in  the  current  location" 
PROCFDUPE   undefined  :  I  ink  ); 

"causes  all  previous  uses  of  <l>  to  bt  for 9 often" 

"raises  an  error  if  <to(l)>  has  occurred  but  there" 

"has  been  no  <define(l)>" 
PROCEDURE   defined  :  I  ink); 

"causes  any  instance  of  <  t  o  d ) >  to  qenerate  2    b  y  t  <*  s  " 

"in  the  binary  image  that  refer  to  the  current  location" 

"raises  an  error  if  <defined)>  has  already  occurred" 
PROCEDURE   to(l:link); 

"generates  ?    bytes  of  address  in  the  I  inary  image" 
FUNCTION   definedd:  link) -.boolean; 

"TRUE  if  <defined)>  has  been  executed" 
FUNCTION   used(  I  : link) : boolean; 

"TPUE  if  <tod)>  has  been  executed" 


"Other  procedures  external  to  this  definition" 
PROCEDURE   compi  le_tag (command) ; 

"performs  a  non  context  dependant  compilation  of  the  command" 

"The  main  procedure  tor  compiling  a  line" 
PROCEDURE  compile_a_line; 
H  E  G  I  N 

CAbE  this_command  OF 

unit  : 

entry  : 

arrow  : 

join  : 

spec  s  : 

endarrow  : 

ne ve r _ends _ j udq i ng  : 

sometimes_ends_judaina  : 

always_ends_judging  : 

ELSE 

end; 

END  " compile_a_line"; 


c  _uni  t ; 

c_ent  ry ; 

c  _ar  row; 

c  _ j  oi  n; 

c_spec  s; 

c  _  e  n  d  a  r  r  o  «( ; 

c  _  w  e  a  k  ; 

c  _st rona; 

c_stronger; 

compi le_tdi(this_command) 
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"C  omm 
PROff 
B  t  (.  I  N 


and  specific  code  neneration  procedures 
D  U  R  F  c  unit; 


END 


ASSERT  state  IN  o.renular; 

c  _enoa  r  r ow / 

PSSFRT  state  IN  {s_renular}; 

ASSFRT  i  nput  _reque  s  t  ed  -  false; 

IF  u  sed ( L  _endun  it) 

THEN  PFMN 

define(l_endunit  ); 

unc  ef  ine( L_enaunit ) ; 

state  :=  state  +  <s-judgino}  +  (y_regutar 

end; 

IF     N0T(     state    =     O     ) 
THEN     PEC IN 

codeout (o_return_if_set>; 

codeout (b_dojoin) ; 

codeout (o_end_main_unit); 

end; 

compile_ta^  (unit); 

stcte  :=  g_regular  +  -Cs_judoinq}/' 

codeout (o_tranch_i  t_set ); 

codeout  <b_search); 

to(l_judnir»g); 

st.ite     :=    state    -    <  s  _  j  u doing}; 

no_arrow_in_unit     :=    true; 

c  unit"; 


-  -Cs_regular>); 


IN  {s-re~ular}; 

r eques  ted  =  false; 

=  O  ) 


PPOCFDUPE  c.mtry; 
FECI  N 

ASSERT  state  IN  g -regular; 

c-enda  r  row ; 

ASSERT     state 

ASSERT     input, 

IF     N0T(     state 

THEN     BEGIN 

codeout (o_hranch) ; 

to(l_regular); 

stte     : -    { > ; 

end; 

coirpile_ta<:  (unit); 
s  t .  <  t  e    :  -    gregular    +    Cs_judc<ing>; 
codeout  ( o  _  t  ranch_i  f_set ); 
codeout  <b_seerch); 
to  ( I  _j udgi ng>  '» 

st.-te  :r  state  -  {s_judqing}; 
define(l_rpaular); 
un  oefine  (l_regular); 
no_arrow_in_unit  :=-  true; 
END  "c_entry"; 
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PROCEDURE  c.srrcw; 
BEGIN 

ASSERT  state  IN  g_reqular; 

c_enda  r  row ; 

ASSERT  state  IN  <s_reqular>; 

ASSERT  i nput .requested  =  false; 

compile_tao(arrow) ; 

state  :=  {s_postarrou>; 

no_a rrow_i n_un i t  :=  false; 
END  "c  arrow"; 


PROCEDURE  c_join; 
BEGIN 

ASSERT  state  IN  g_regular; 
IF  used(l_j  udq  i  ng) 
THEN  PFGIN 

define(l_judginq); 

undef  ine( l_judqinq); 

st.te  :=  state  +  -Cs_judginq>; 

end; 

IF  (NOT  def  ined(  l_input ) )  Af^D  ((s-postarrow)  IN  state) 

THEN  def int (l_input )  ; 

comp  i I e  _t  ao (do ) ; 

state_changes_in_joined_unit; 

IF  {s_ j udqi na}  IN  state 

THEN  BEGIN 

codeout (o_branch_if_set_reset  ); 

codeout (b_search); 

codeout (b_ok_no_specs); 

t o ( I _  j  udgi  ng )  i 

end; 

state  :=  state  -  {s_judging>; 

IF    <s_specs>    IN    state 

THEN  BEGIN 

codeout (o_branch_if_set_rPset ); 

codeout (b_search); 

codeout (b_specs); 

IF  detined(l_specs) 

THFN  to(l_specs) 

F  LS  E  t o ( I _mar kup  )  ; 

end; 

state  :-  state  -  (s_specs); 
IF  (s.pndarrow)  IN  state 
THFN  P  E  (-,  I N 

codeout (o_branch_if_set); 

codeout (b_search)  ; 

to(lendarrow); 


FND 


end; 

stite 
ASSERT 
c_ jo  in 


=  state  -  {s_endarrow>; 
state  IN  q_regular; 
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procedure  c .specs; 

E  E  G  T  N 

ASSERT  state  IN  g.regular; 
pre_judqinq# 

ASSERT  ^tate  IN  { s _ j ud -i ng} ; 
IF  {s_juaaing}  IN  state 
THEN  P  F  6 1 N 

corrpi  I  e_taq(specs); 

corteout (o_branch) ; 

to(l_judginq); 
TND  r  L  S  f  error ('  command  will  never  be  executed* ); 
unuefine ( I  specs); 
aetine(l_srecs); 

st. te:=  {s-specs/S-postjudqina>; 
codeout (o_markup); 
stite:=  <s_postspecsj; 
p  o  s  t  _  j  u  d  r.  i  n  q  ,* 
END  "c.specs"; 


PROfTDURE  c.wpak; 
I-  E  G  I  N 

ASSERT  state  IN  g_re oular; 
pre  _  judging; 

ASSERT  state  IN  {s_j udgi ng} ; 
IF  -Cs_juaginq>  IN  state 
THEN  BEGIN 

con.f  i  le_taq(this_command); 
codeout  (o_branch) ; 
to(l_judge); 
stte  :=  <>; 
FND  FLST  frrorCcommanci  will  n^ver 
post  _j  udqi  no; 
END  "c  veak"; 


be  executed')/' 


PROlLDUPE  c_strnn,; 
P  E  6  I  N 

»  S 

pr 

AS 

IF 

TH 


IN  q  renuUr; 


LND 


bN 

v>o 
■c 


SERT  state 
e_  j  udo in g ; 
SERT  state  IN  (sjud^nq); 

•Cs_judr;inci>  IN  state 
FN  Pb  t,  IN 

c  o  rn  p  i  I  e  _  t  a  q  ( t  r.  i  s  _  c  o  m  m  a  n  d )  ; 

st. te  :=  state  +  is _pos t j udgi no) ; 

codeout (o_branch_i  t_set ) ; 

coceout (b_search); 

to*  I  _  j  udge ) ; 

st-te  :=  state  -  \s_juciginq); 
D  ELSF  errorCthis  command  will  never  be  executed'); 
st  _  j  u<"  ii  no  ; 
s  t  r  o '  1 1  " ; 
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PROCEDURE    c_stronger; 
REGIf* 

ASSERT  state  IN  g_regular; 

pre_jucfainq; 

ASSERT  state  IN  {s _j udoing>; 

IF  <s_judging>  IN  state 

THEN  BEGIN 

com pi le_tao(this_command); 
state  :=  {s_post j udgi np>; 

END  ELSE  e rror (' command  will  never  he  executed'); 

post_ju'Jging; 
END  "c  stroncer"; 


PROCEDURE  c_endarrow; 
BEG  I  n 

ASSERT  state  IN  g_requlsr; 
IF  no_ar row _in_uni t 
THEN  PEG  IN 

IF  <s_regular>  IN  state 
THFN  BEGIN 

codeout (o_branch_on_reset ) i 

codeout (b_search_ok_no_specs) ; 

to(l _regu I ar) ; 
fnd; 

state  :=  state  -  {s.reoular); 
IF  NOT(  state  =  O  ) 
THEN  HEGIN 

codeout (o_branch); 

to(l_end_unit); 
fnd; 

s  t  - 1  e  :  =  O  ; 

IF  (u sed (  I  _ma rkup) )  OR  (used ( I _enda r row ) ) 
THEN  l)EGIN~ 

Jef  i  ne ( I _markup ) ; 

-iefine(lendarrow)  ; 

unde'fine  (l_markup)  ; 

un define* l_endarrow) ; 

codeout  Co_set_status) ; 

codeout (bsearch); 

state  :=  state  ♦  (s.endarrow/s.specs); 

end; 

IF  used ( I _ j  udoi  ng ) 
TFEN  TEG  IN 

^efine(l_judaing); 

undef  ine ( l_judqinc); 

state     :=    state    ♦    <s_judying>; 

end; 

IF  NOT(  state  =  O  ) 
THEN  TEGIN 

codeout (o_branch); 

t  o  ( I _endun  it); 

end; 
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"c_endarrcw  ...  continued" 

fND  ELf>F  F3FGIN  "there  wis  a  previous  arrow  in  this  unit" 
pre_judoino; 

ASSERT  st^te  IN  < s _ j udc.  i n j>; 
IF  fs_judginq}  T  N  state 
THEN  i  E  6  I N 

rompile_taq(no); 
:t?te  :=  <s_post j udg i ng> ; 
IF  def i ned ( I _specs ) 
THEN  RFGIN 

codrout (o-branch); 
to(l_specs); 
state  :  =  O; 
F  N  d  ; 
end; 

ASSFRT  state  IN  {  s  _po  s  t  j  uric,  i  nq  3  ; 
IF  used(Lmarkup) 
THEN  n F  6 1 N 

refine(L_fnarkup); 

undefine  (  l_markup)  *" 

state     :=    state    +    (s_spec s / s_post j udc i ng> ; 

end; 

IF  (<s_specs>  IN  state)  OR  (-Cs  _post  jurioino}  in  state) 

THENfEuIN 

rode out ( o -markup) i 

state  :=  {s_postSfecs>/ 
end; 

ASSERT  state  IN  {s_postspecs>; 
If  use d ( I  enda r row ) 
THEN  l-EGIN 

r'efine<  l_endarrow); 

un  ciefine  (  l_end  arrow)  ; 

state  :  =■  state  +  (s_endarrow/S_postspecs)» 
END  ; 

IF  ({s_postspecs>  IN  state)  OR  ({s_endarrow>  IN  state) 
T  Hf  N  •  F  6  I  N 

rodeout (o_endarrow) ; 

st«.*te  :=  (s„postarrott/s_reouldr); 

codeout (o_branch_if_set ); 

codeout (b_search); 

to(linput); 

state  :=  state  -  < s_post a r row) / 

e  \  d  ; 
F  N  d  ; 

post  _jud'nno; 
unoefine(l_specs)/* 
undefine  (I _input); 
input  reouested  :=  false; 
r,o_arrow_in_unit  :=  true; 
ASSERT  -jtate  IN  {s.recjldr}; 
E ND  "c  endar  r  ow "; 
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PROCEDURE 

BEGIN 

ASSE 
IF  { 

THEN 


end; 

stat 

IF  i. 
THEN 


end; 

Stat 

IF  i 

THEN 


fnd; 

Stat 
ASSE 
IF  N 
THEN 


end; 
if  i 

THEN 


pre_j  udgi  ng; 

RT  state  IN  g_regular; 
s_rer»ular}  IN  state 

BEGIN 

cooeout (o_branch_on_reset ); 

codeout (b_search_ok_no_specs); 

to(l_regular); 

e  :=  state  -  <s_reqular>; 
s_post j udgi ng}  IN  state 

BEbIN 

codeout (o_branch_if_reset  ); 

codeout (b_search_specs); 

IF  aet ined ( I _specs ) 

THEN  to(L_specs) 

ELSE  to(l_markup)/' 

e  :=  state  -  <s_post judging}; 
s_postspecs}  IN  state 
BEbIN 

IF  <s_postarrow}  TN  state 
THEN  <"•  E  G  I  N 

codeout (c_branch_if_reset ) ; 

codeout (b_ok_no) ; 

t  o ( L  _input ) ; 
fnd; 

st.jte  :=  state  -  {s_postarrow}; 
codeout  (o_branch); 
t  o (  l_endar row  ) ; 

e  :-    state  -  { s _pos t spec s} ; 
RT  state  IN  <s_postarrow}; 
OT  r:efined(l_input) 

B  E  b  I  N 

define(linput); 

State     :=    state    +    {s.postarrow}/ 

ASSERT    NOT    incut .requested; 

s_pfiStarrow}    1^     state 

f'ecin 

IF  NOT  inout .request ed 
THEN  (-EGIN 

codeout  <o_readline); 

input .request ed  :=  true; 

state  :=  {s_judqina}; 
END  ELSF  BEGIN 

codeout (t ranch); 

tod.input); 

state  :=  O; 


END 


end; 
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"pr  ■  _  judo  in.,  ...  continued" 

If  used<l_judcinq) 

THEN  I?  E  (.  I N 

define(t_judqinq)/ 

un  pfine(l_judoinn); 

st.te  :=  state  ♦  {s_junginu>; 

end; 
FND  "pre_jud<  ini"; 


PROCEDURE  stte_ch?nqes_in_joined_unit; 

!•  E  (i  I  N 


IF 


IF 


(s_rost arro 
"th(  joined 
"th'n  if  it 
" j  u ,  q inq  st 


IF 

THEN 


■Cs  _  i  udvi  i 
"th«  uni 
"a  j  udo i 
{  s  _  p  o  s  t  j 

st  te  := 
"th  unit 
"a  -judqe 


nu) 
t  i 
no 
ud  : 

=  s 
i 
c 


FND 


"a  j  udoing 

IF   -Cs  _post  s  pec 

Mth>  unit  i 

"then  a     jud 

s  t .  <  t  e  changes  i 


w>  I 
un  i 
con 
ate 
IN 
s  jo 
comm 
inq} 
tate 
s  en 
ont  i 
comm 
s>  1 
s  en 
q  i  n  3 
n_jo 


N  st 
t  is 
tain 
wi  11 
stat 
i  ned 
and 

IN 

+  { 
t  e  re 
nue- 
and 
N  st 
t  ere 

com 
i  ned 


ent 
s  a 

be 
e  TH 

i  n 
may 
stat 
s  _  j  u 
d  in 

may 
may 
ate 
d  i  n 
mand 

un  i 


T  H  E  N 
ered 
j  U  d  q 
ent  e 
EN  s 
j  ud  j 
end 
e 
dcj  i  n 

or 

r  ee 
caub 
THEN 

or 

may 

t"; 


stnte  :=  state  ♦  <s_judqinq 

in  postarrow  state" 
inq  command" 
red" 

tate  :=  state  ♦  {s_postjudgi 
inq  state  or  enters  that  sta 
judo  in a  in  that  unit" 

o/s_specs/S_postspecs>; 
enters  postjuuqino  state" 
nter  judginq  state" 
e  it  to  enter  search-specs" 

state  :=  state  +  {s_endarro 
enters  posts  pecs  state" 

st.rt  endarrow  search  state 


>; 


nq>; 
te" 


w>; 


PRUTEDURt  p  o  s  t  _  j  u  d  q  i  n  q  /* 
PEG  IN 

IF  used(l_renular) 
t  h  r  n  p  r  (  i  n 

define  <l_re<iular)# 
uriv.ef  ine(l_rc"ular); 
stte     :=    statp    +    <s-recul>r>; 
E  N  D  ; 
END     "post _ j udni nq"; 


APPENDIX  F  -  TERMINAL  TRANSMISSION  CODES  AND  BUFFERS 
E.1.   THE  TRANSMISSION  CODE/  AN  EXTENSION  OF  ASCII 
E.1.1.   PRINTING  CHARACTERS 
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0       1 


First   Digit 
23456789ABCD 


E      F 


m 
0 

sp 

J& 

@ 

P 

* 

P 

- 

Tf 

1 

» 

1 

ft 

Q 

a 

q 

Oi 

2 

■ 

2 

B 

R 

b 

r 

P 

P 

3 

# 

3 

C 

S 

c 

s 

2 

C 

4 

$ 

4 

D 

T 

d 

t 

A 

S 

5 

% 

5 

E 

U 

e 

Li 

6 

& 

6 

F 

V 

f 

V 

7 

• 

7 

G 

w 

g 

Ul 

- 

e 

fa) 

8 

( 

e 

H 

X 

h 

X 

n 

9 

) 

9 

I 

Y 

i 

y 

u 

ft 

* 

• 
• 

J 

Z 

J 

z 

X 

B 

♦ 

• 

» 

K 

[ 

k 

{ 

♦- 

< 

C 

> 

< 

L 

\ 

1 

1 

# 

1 

4 

X 

■ 

D 

- 

- 

M 

3 

m 

} 

* 

-♦ 

j* 

> 

E 

. 

> 

N 

* 

n 

*v 

> 

t 

«M 

F 

/ 

? 

0 

o 

+ 

> 

♦ 

0 
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E.1  .2 


CONTROL  CHARACTFRS  (COLUMNS  0  A N D  1) 


HEX:   NAME:   USE: 


rr 

NUL 

01 

SOH 

0? 

STX 

03 

ETX 

04 

EOT 

cs 

FNQ 

0* 

ACK 

07 

PEL 

0* 

BS 

OV 

NT 

OA 

LF 

OR 

VT 

oc 

F  F 

OD 

CP 

OE 

SO 

OF 

SI 

10 

DLE 

1 1 

DC1 

12 

DC2 

13 

DC3 

14 

DC4 

1  5 

NAK 

16 

SYN 

17 

ETP 

18 

c  a  r. 

19 

EM 

1  A 

SUH 

1R 

ESC 

1C 

FS 

11) 

GS 

1  F 

RS 

1  F 

US 

i  mor ed 

home  (X,M  set  0/  Y  snt  AV«S). 

use  normal  character  set  Csee  t.1.13. 

use  user  provided  charset  Csee  DLE], 

■force  buffered  material  to  screen. 

*  *  *  onqu  ire 

***  acknowledge 

ring  be  I  I  . 

backspace  (X  set  X - P )  . 

tab  (on  input  only). 

linefeed  (Y  set  Y-16). 

vert  ical  tab  (Y  set  Y  +  16)  . 

tormfeed  (screen  erase/  home/  mode  write) 

carriage  return  (X  set  M/  Y  set  Y-16). 

superscript  (Y  set  Y+'O  keyboard  SUPFR1. 

subscript  (Y  set  Y-5)   keyboard  SUM. 


data 
a  t  m 
dot 
line 
ex  te 

*  *  * 
*** 

*  ** 
cane 
set 

SubS 

esca 

touc 
f^xt  e 

* 


block  prefix  (binary  data/  charsets)  . 
ode.  (followinq  non  control  codes  ..) 
mode.  (.  are  interpreted  in  oroups  ..) 
.mode  (.  of  3  as  screen  coordinates  ) 
nded  graphics  mode  (for  smart  terminals) 
negative  acknowledge 
synch  ron  i  se 

tnd  of  transmission  block 
el  (reserved  for  special  editing), 
mode  (following  byte  is  mode), 
titute  -  set  fth  hit  in  next  character, 
pe  to  special  controls  Csee  t  .  1 .  3  J  . 
h  control  (following  byte  is  data), 
rnal  device  prefix  (text  mooe). 


***  communications  control 
*    unassioned 
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[.1.3 


ESCAPE  CHARACTERS  (COLUMNS  8  AND  9) 


FSCAPE  KEY:   HEX 


NAME  : 


EDITING  FUNCTION: 


S 
A 
B 
C 
D 
E 
F 
G 
H 
I 
J 
K 
L 
M 
N 
0 


80 

81 
8? 
83 
8  A 

85 
86 
8  7 
88 
*9 
£A 
^P 
8C 
<^D 

*F 


STOP 

DATA 

LAB 

BACK 

NEXT 

HELP 

ANS 

COPY 
EDIT 
ERASE 

( squn  re) 
MICRO 
SUPER 
SUB 


copy  one  word 

restore  word  from  line  buffer 

erase  character 

copy  one  cha  rac  te  r 


90 
91 
9? 
93 
94 
95 
96 
97 
9F 
99 
9A 
9B 
9C 
VD 
9E 
9F 


ST0P1 

DATA1 

LAB1 

BACK1 

NFXT1 

HELP1 

TkRM 

C0PY1 
ED1T1 
FRASE1 


copy  rest  of 
copy  rest  of 
erase  word 


line 

edit  buf  f er 


(square ) 1 
FONT    MICR01 
{ 
TIMEUP        i 


SUPFP1  is  0E  ) 
SUB1  is  OF    } 
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F  .  ?  .   BUFFER  TYPES  HETWFEN  INTERFRETtR  AND  DEVICE  HANDLER 


To  the  user  task/  the  terminal  is  accessed  as  two  separate 
virtual  devices.  >ne  device/  the  "line  editor"  provides  services 
thot  are  a  superset  of  the  services  provided  by  the  standard 
teletype  handler;  this  device  provides  all  of  the  line  editing  and 
input  echoinc  services.  The  other  device/  the  "key  queuer"  manaqes 
the  collection  of  input  characters/  with  provisions  for  non-echoing 
input  such  as  the  TUTOR  -pause-  and  -collect-  as  well  as  the  -press- 
service  which  simulates  a  keypress  at  the  terminal. 


<re<id> 
<  wr  i  t  e> 


software 


line 
editor 


<(...use>  -*- 
<  p  r  e  s  s  >  — 


key 

queuer 


har dwa  re 


d  i  s  p  I  a  v 
s  c  r een 


k  e  ybna  rdl 


The  following  sections  are  user  interface  specifications  for 
these  virtual  devices  in  terms  cf  the  input/output  functions  of  the 
MAX  IV  operating  system  on  the  KodComp  IV  computer.  All  of  these 
input  output  functions  take  as  their  parameter  a  'users  file  table' 
which  contains  the  parameters  (or  pointers  to  parameters)  for  the 
c  a  I  I  . 
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USERS  FILE  TABLE  FORMAT  FOR  TRANSACTIONS 


-1 


Inte 

Poi 

r 

{  x  x 


Tra 
Fi  I 
<01 


Opt 
Tro 
Sys 
{01 


Ir'ys 
I  np 
Buf 


rpre t at 

nt  er  to 

'  f  e  r  e  n  c 

x  xx  xx7x 

DE=xO: 

=  f  1  : 

=  11: 

7  :  use 

nsac  t  io 
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1.2.7.       TRANSACTIONS  DEFINED  TO  THE  LINE  EDITOR 

MODE  (selected  by  bits  STD  and  BIN  of  word  2,     E.2.1.) 


CALL 


read 


wr  1 1  e 


STD  .  ASCII 


NONSTD.  ASCII  STD.  BINARY     NONSTD.  BINARY 


one  line  in 
(7  bit  chars) 


one     line    with 

crraqe 
control 


one     recoru    in 
(8    bit     chars) 


one  buffer 

with  emoeded 
cont  ro I  chars 


reserved  for 

ST,drt 
terminals 


r p  served  for 
s  in  a  r  t 
term  inn  Is 


get  contents 
of  i  ndi  cated 
buffer 


set  cont  ent  s 
of  indicated 
buf  f  er s 


rewind  (erase  screen/  clear  all  state  information) 

oackfile  (ignored) 

backrecord  (ignored) 

advance  rpcnrd  (clears  line  editing  state) 

advance  file  (see  rewind) 

write  end  of  file  (see  rewind) 

homt-  (see  rewind) 


The  nonstandard  binary  read  and  write  transactions  use  only  the 
buffer  specification  option  bits  in  the  extended  option  word.  On 
read  only  one  buffer  may  be  specified. 

The  nonstandard  ASCII  read  interprets  all  of  the  option  bits  in 
the  extended  option  word.  The  buffer  specification  bits  specify 
which  (if  dny)  of  the  buffers  should  be  cleared  before  any  other 
processing  takes  [lace.  The  standard  ASCII  redd  defaults  these 
options  so  that  the  read  behaves  like  a  read  of  one  line  from  a 
t e I et ype  . 

All  ATCII  reads  interpret  the  DDO  bit  as  inhibiting  prompting 
for  input  (prompts  consist  of  an  arrow  [>3  preceded  by  a  carrage 
return  if  th<  RA  bit  is  not  set). 


All  writes  may  interrupt  all  reods/  with  the  read  beino 
automatically  resumed  ("as  if"  there  were  no  interruption)  when  the 
write  terminates.  In  addition/  the  DDO  bit  (when  used  with  write) 
causes  the  current  display  mode  and  location  to  be  saved  before  the 
write  and  restored  afterwards  (i.e.  for  system  messages). 

If  a  keylist  is  present/  bits  set  in  it  correspond  to 
characters  that  will  terminate  the  current  reaa.  Tf  such  a  list  is 
not  present/  only  thp  NhXT  and  CR  keys  will  be  active.  In  the 
standard  ASCII  read/  the  terminating  key  is  never  returned;  in  the 
nonstandard  ASCII  read/  it  is  always  returned  as  the  last  item  in 
the  buffer. 


E.2.3.   TRANSACTIONS  DEFINED  TO  THE  KEY  QUEUER 

MODE  (selected  by  bits  STD  and  BIN  of  word  2/  E.2.1.) 
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CALL 


STD  .  ASCI  I 


NONSTD.  ASCII  STD.  BINARY    NONSTD.  BINARY 


read 

from  queue 
(7  tit  chars) 

from  queue 
(fc  bit  chars ) 

ignored 

i  gno red 

writp 

line  of  keys 
with  Corraqe 
cont  rol 

list  of  keys 

with  embeded 
cont  rol  chars 

i  gnored 

i  gnored 

rewind  (dumps  the  queue) 

bac  k  file  ( i  ono  red) 

back  record  (ignored) 

advance  record  (inserts  NEXT  in  t,ueue) 

advance  file  (see  rewind) 

write  end  of  file  (see  rewind) 

home  (see  rewind) 


The  DDO  option  for  all  of  these  transactions  causes  the  queue 
to  he  cleareo  before  processing  continues. 

The  NT  option  applies  only  to  the  read  operations*  and  causes  a 
wait  until  the  number  of  keys  asked  for  can  be  tronsfered.  If  the 
NT  option  is  not  selected*  the  reao  operations  will  return  only 
those  keys  currently  in  the  queue*  or  nothing  if  none  were  currently 

queued. 

If  a  keylist  is  specified*  it  is  usen  to  filter  the  input 
returned  to  the  user*  i.e.  keys  not  in  the  list  *ill  be  discarded 
instead  of  being  placed  in  the  users  buffer. 


BLIOCRAPHIC  DATA 
IEET 


1.  Report  No. 

UIUCDCS-R-77-868 


Tit le  and  Subtitle 

Run  Time  Support  for  the  TUTOR  Language  on  a  Small  Computer 
System 


3.  Recipient's  Accession  No. 


5.  Report  Date 

May,  1977 


Author(s) 


Douglas  W.   Jones 


8.   Performing  Organization  Rept. 
No. 


Performing  Organization  Name  and  Address 

Department  of  Computer  Science 
University  of  Illinois 
Urbana,  IL   61801 


10.  Project/Task/Work  Unit  No. 


11.  Contract/Grant  No. 


13.  Type  of  Report  &  Period 
Covered 

Master's  Thesis 


Sponsoring  Organization  Name  and  Address 

Medical  Computing  Laboratory 

190  School  of  Basic  Medical  Sciences 

University  of  Illinois 

Urbana,  IL  61801 

Supplementary  Notes 

Revision  of  Masters  Thesis  deposited  with  the  University  of  Illinois  in  May,  1976 


14. 


Abstracts 

This  report  contai 
VTO  computer-aided  in 
Cementation  on  a  sma 
;ir  reasons  are  outli 
?c  i  a  1  emphasis  is  pi  a 
-ge  PLATO  system. 

Appendices  contain 
lents  of  the  implemen 
Iging  control  structu 
'  the  user  terminals, 
the  interpreter. 


ns  an  analysis  of  the  TUTOR  programming  language  used  on  the 
struction  system.  The  analysis  centers  on  the  requirements  for 
11  to  medium  scale  computer  system.  Implementation  choices  and 
ned,  and  the  results  of  one  such  implementation  are  presented, 
ced  on  the  desire  for  program  transportability  to  and  from  the 

descriptions  and  specifications  of  the  critical  software  com- 
tation,  including  compiler  specifications  for  TUTOR'S  response 
res,  input/output  interface  and  character  set  specifications 

and  specifications  of  the  framework  and  basic  instruction  set 


.Key  Words  and  Document  Analysis.     17a.   Descriptors 

igramming  Languages 
npilers 
terpreters 

>ut/0utput  Routines 
(ching  Machines 
I -Machine  Systems 


'  Identifiers/Open-Ended  Terms 

ITO  (computer  system) 

LOR  (programming  language) 


7  COSATI  Field/Group 
81  vailability  Statement 


1  NTIS-3B   (10-70) 


19.  Security  Class  (This 
Report) 

UNCLASSIFIFT 


20.  Security  Class  (This 

Page 
UNCLASSIFIED 


21.   No.  of  Pages 

92 


22.  Price 


USCOMM-DC    40329-P71 


'<* 


?«o 


